This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Component Design

Component Design

Module Detailled Design

Component Documentation

1 - ES100A_SysStMod

System States and Modes

FDD #ES100A

1. High Level Description 3

2. Derived Requirements 3

3. Sub-Function Data Flow 3

4. Design Rationale 3

5. Sub-Functions 3

5.1.1. Hardware Related Design 3

5.1.2. Software Related Design 3

6. Timing / Execution Constraints 4

6.1. Rationale / Comments 4

6.2. Rates and State Execution 4

7. Serial Communications Interfaces 4

8. Revision Record & Change Approval 5

High Level Description

This function controls the primary system state machine for the application. New states are computed based on current state and the inputs to the function.

Four states are identified – OFF, WARM INIT, DISABLE and ENABLE.

Derived Requirements

All requirements are contained in the ES100A_SysStMod DOORs module. All requirements are derived.

Sub-Function Data Flow

Refer to the accompanying Simulink Model in the Functional Design Package.

Design Rationale

  1. The design was decided to take a lookup table based approach to allow for future flexibility should it be required. Changes might only require constant changes rather than a redesign.

  2. Transition Vector was developed to cover all current states – see the “Vector Analysis” spreadsheet included in the functional design package.

  3. Inputs for the following place certain requirements on the owning function:

    1. SysStReqDi: Required to indicate TRUE if the state output control function has ramped assist to zero due to the Diagnostic input or the normal operational input. Things like start/stop are excluded from this to prevent transition to disable using that function (for improved start up times).

    2. SysStFltOutpReqDi: Required to indicate TRUE if the diagnostic manager is responsible for removing output and has completed the ramp out (which could be a step in rapid shutdown mode).

Graphical model of the state machine implementation

Sub-Functions

Refer to the accompanying Simulink Model in the Functional Design Package.

Requirements are linked between DOORs FR Document ES100A_SysStMod and the Simulink Model.

None

Refer to the accompanying Simulink Model in the Functional Design Package.

Timing / Execution Constraints

Rationale / Comments

The states and modes function shall be run at the end of the main control loop (2ms). This is to reduce lag in shutdown, requiring all inputs to the state machine to be computed in the same loop prior to executing the function.

Rates and State Execution

In general, the system state columns should be filled in as “Execute” or “Do Not Execute”

Sub-Function NameRate (ms)Cold InitWARM INITENABLEDISABLEOFF
Refer to the *.m file in the Functional Design Package.See m fileDo Not ExecuteExecuteExecuteExecuteExecute

Serial Communications Interfaces

Nexteer Manufacturing Services will be used to read out the SysStMod output (SysSt)

Revision Record & Change Approval

RevDateChange Control #DrwChange Description
01.00.0024FE15EA4_144MKInitial Release

2 - ES100A_SysStMod FDD Peer Review Checklist

Nexteer_Template_V1.0

Overview

Peer Review Instructions
Technical Review Checklist
Template Change Log

Sheet 1: Peer Review Instructions

Instructions for Functional Design Package Peer Review




PRE-MEETING


Function OwnerConfirm that requirements are reviewed and approved PRIOR to the FDP peer review

Function OwnerStart with latest version of the template for any "first reviews" - Continue to use existing temmplate for re-reviews

Function OwnerProvide the functional design package (changed documents) to the invited attendees 1-2 working days in advance of review

Function OwnerNotify the assigned peer reviewer and make sure they are prepared to do their function in the meeting

Function OwnerIdentify necessary attendance and invite to meeting

Function OwnerComplete the "Author" column information for sections 1 through 3 prior to the review

Function OwnerComplete the attendance invitation list in section 5

Function OwnerFor Re-reviews only: Complete the column "remarks by author" to identify actions taken to address items found in earlier reviews.



DURING MEETING


Function OwnerPresent document changes to the review team

Peer ReviewerCapture attendance of the review

Peer ReviewerCapture actions and issues in section 4. Identify issue summary, Document type, Reference (Requirement ID, section number, etc), Defect Type and indicate status as "OPEN"



POST MEETING


Function OwnerFollow up on all "open" items. Update "Summary of Resolution" to indicate what was done or decided.

Function OwnerSchedule follow up review OR review open items with peer reviewer and obtain agreement to close

Peer ReviewerClose change request in system and confirm all associated tasks are complete. Upload peer review checklist (this document) with any FDP updates

Sheet 2: Technical Review Checklist

Technical Review Checklist - Template Version 01.00.05







Product NameElectric Power SteeringElectrical Arch.4Review ScopeDefect TypeNumbers




YesClosedFR
Function NameES100A SysStMod

EA4#4826

Also changed En to Ena in the input names to match AutoSAR naming convention		Requirement0




NoRejectedFDD
AuthorSamanth Kumaraswamy

Interface0




NAOpenModel


EffortDesign0






FMEA


Review Effort(Hrs.)0.10Standards0






*.m File


Corr+Verf effort(Hrs.)
Documentation0






Cal Process


Total Effort (Hrs.)0.10Others0













Total0







Checklist No.Description of CheckAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. ReviewerAuthor: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewerAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







1Section 1: TECHNICAL CHECK













1.1Confirm that all signal inputs into the FDP (Functional Design Package) are contained within and exactly named as the "Available_Nexteer_Signals.m" states.NANA











1.2Confirm any removed signal inputs from the design have been removed from the "Available_Nexteer_Signals.m" file.NANA











1.3Confirm all signals and parameters (outputs, calibrations, constants, non-volatile memory) used in the *.m file and the design conform to the AutoSAR naming convention documentation.NANA











1.4Confirm *.m file has been provided to the "Available_Signal_Names" Author.NANA











1.5Confirm Electrical Systems interface map is updated to reflect the FDP (signal IO)NANA











2Section 2: Safety CHECKAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. ReviewerAuthor: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewerAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







2.1Confirm that the functional DFMEA is up to date based on the design in the current package.NANA











2.2Confirm that Safety requirements (ASIL A - D) are referenced in the design documents.YesYes











3Section 3: Lessons LearnedAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. ReviewerAuthor: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewerAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







3.1Have functions depending upon system state been reviewed for need to be executed at the 2ms rate to avoid system lag issues?NANA











3.2Have all diagnostics (NTCs) been confirmed to show logic to invoke a diagnostic "PASS" for control of the status byte at the customer level.NANA











3.3Has the requirements traceability steps used the RMI steps as defined in the FDD authoring spec to generate the traceability report?YesYes











3.4Has the requirements traceability report been verified to only contain ONLY requirements from the FR.YesYes











3.5Confirm that all PIM that does NOT have an initialization value of zero is initialized in an INIT function.NANA











3.6Confirm if NVM is used, the NVM is defined in structuresNANA











3.7If the function uses NVM, confirm that the m file identifies the "write" eventNANA











4Section 4: Issues / Actions IdentifiedDocumentReferenceSummary of resolutionAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status























5Section 5: APPROVALS













RoleFirst ReviewDateAttendanceApproval?










Function Owner*Muragesh Asundi3/31/2016YesYes










Peer Reviewer*NayeemYes










EPDT Engineer












ES Engineer












Software Lead












Hardware Lead












Test Lead












Safety Lead












RoleSecond Review (if required)DateAttendanceApproval?










Function Owner*<Name - if invited>













Peer Reviewer*<Name - if invited>











EPDT Engineer<Name - if invited>











ES Engineer<Name - if invited>











Software Lead<Name - if invited>











Hardware Lead<Name - if invited>











Test Lead<Name - if invited>











Safety Lead<Name - if invited>











RoleAdd more if necessaryDateAttendanceApproval?










































P.S.:Yes indicates adherence














No indicates non-adherence, reviewer shall provide suitable comments at the end of this document for each point.














NA indicates not applicable













Sheet 3: Template Change Log

RevChangeAuthor
01.00.05Added lesson learned #3.5MDK
01.00.06Added lesson learned #3.6, 3.7 - Structure and writing of NVM in mfiles and models.MDK




















































































3 - VectorAnalysis



Transition Vector
Next State Tables (Columns Represent Current State)















Dec Value
AFCRW
OFF
WI
EN
DI















0
00000
OFF
DI
EN
OFF
1
00001
OFF
DI
EN
OFF
2
00010
OFF
DI
DI
OFF
3
00011
OFF
DI
DI
OFF
4
00100
OFF
DI
EN
OFF
5
00101
OFF
DI
EN
OFF
6
00110
OFF
DI
DI
OFF
7
00111
OFF
DI
DI
OFF
8
01000
OFF
DI
EN
OFF
9
01001
OFF
DI
EN
OFF
10
01010
OFF
DI
DI
OFF
11
01011
OFF
DI
DI
OFF
12
01100
OFF
DI
EN
OFF
13
01101
OFF
DI
EN
OFF
14
01110
OFF
DI
DI
OFF
15
01111
OFF
DI
DI
OFF
16
10000
WI
WI
EN
DI
17
10001
WI
WI
EN
DI
18
10010
WI
WI
DI
DI
19
10011
WI
WI
DI
DI
20
10100
WI
WI
EN
WI
21
10101
WI
EN
EN
WI
22
10110
WI
WI
DI
WI
23
10111
WI
WI
DI
WI
24
11000
WI
DI
EN
DI
25
11001
WI
DI
EN
DI
26
11010
WI
DI
DI
DI
27
11011
WI
DI
DI
DI
28
11100
WI
DI
EN
DI
29
11101
WI
DI
EN
DI
30
11110
WI
DI
DI
DI
31
11111
WI
DI
DI
DI