1 - requirements

FDDIDSourceFunctionLine(s)StatusComment
.SwFileName.SwFuncName.SwLines.SwStatus.SwComment
ES106A42StHlthSigStc.cStHlthStcPwrDwn_Oper,StHlthSigStc_UpdNvmPim563-572,864-886I
ES106A22StHlthSigStc.cStHlthStcPwrDwn_Oper,StHlthSigStc_GetSigStHlthData,StHlthSigStc_UpdDataSample507,561,760-809,917-953I
ES106A24StHlthSigStc.cStHlthStcPwrDwn_Oper,StHlthSigStc_UpdNvmPim562-571,863-885I
ES106A26StHlthSigStc.cStHlthStcPwrDwn_Oper486-581I
ES106A20StHlthSigStc.cStHlthSigStcInit1412-421I
ES106A21StHlthSigStc.cStHlthStcPwrDwn_Oper,StHlthSigStc_GetSigStHlthData,StHlthSigStc_UpdDataSample506,560,759-808,916-952I
ES106A48StHlthSigStc.cStHlthSigStcInit1358-391I
ES106A49StHlthSigStc.cStHlthSigStcInit1372-375I
ES106A44StHlthSigStc.cStHlthSigStcInit1398-406I
ES106A45StHlthSigStc.cStHlthStcPwrDwn_Oper502I
ES106A28StHlthSigStc.cStHlthStcPwrDwn_Oper487-582I
ES106A43StHlthSigStc.cStHlthSigStcInit1349-392I
ES106A40StHlthSigStc.cClrSigStcHlthData_Oper,StHlthSigStc_ClrDataSample216-232,676-707I
ES106A5StHlthSigStc.cStHlthSigStc_UpdNvmPim147I
ES106A7StHlthSigStc.cStHlthSigStc_UpdNvmPim149I
ES106A6StHlthSigStc.cStHlthSigStc_UpdNvmPim148I
ES106A8StHlthSigStc.cStHlthSigStc_UpdNvmPim150I
ES106A11StHlthSigStc.cUpdStHlthStcData_Oper632-648I
ES106A39StHlthSigStc.cClrSigStcHlthData_Oper,StHlthSigStc_ClrDataSample215-231,675-706I
ES106A12StHlthSigStc.cStHlthStcPwrDwn_Oper463-580I
ES106A15StHlthSigStc.cStHlthStcPwrDwn_Oper,StHlthSigStc_GetSigStHlthData,StHlthSigStc_UpdDataSample504,558,757-806,914-950I
ES106A14StHlthSigStc.cStHlthSigStcInit1410-419I
ES106A17StHlthSigStc.cStHlthSigStcInit1411-420I
ES106A33StHlthSigStc.cStHlthStcPwrDwn_Oper491-586I
ES106A32StHlthSigStc.cStHlthStcPwrDwn_Oper490-585I
ES106A31StHlthSigStc.cStHlthStcPwrDwn_Oper489-584I
ES106A30StHlthSigStc.cStHlthStcPwrDwn_Oper488-583I
ES106A37StHlthSigStc.cStHlthSigStc_GetSigStHlthData737-843I
ES106A50StHlthSigStc.cStHlthSigStcInit1383-389I
ES106A35StHlthSigStc.cUpdStHlthStcData_Oper633-649I
ES106A52StHlthSigStc.cStHlthSigStcInit1394-422I
ES106A18StHlthSigStc.cStHlthStcPwrDwn_Oper,StHlthSigStc_GetSigStHlthData,StHlthSigStc_UpdDataSample505,559,758-807,915-951I

2 - StHlthSigStc Review


Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
PolySpace
Integration Manual


Sheet 1: Summary Sheet
























Rev 1.28-Jun-15

Peer Review Summary Sheet


























Synergy Project Name:


kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. ES106A_StHlthSigStc_Impl
Revision / Baseline:


kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. ES106A_StHlthSigStc_Impl_2.1.0

























Change Owner:


kzshz2: Intended Use: Identify the developer who made the change(s) Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards. Akilan Rathakrishnan
Work CR ID:


EA4#7307





























kzshz2: Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed. Rationale: This will be good information to know when ensuring appropriate reviews have been completed. Modified File Types:















































































































































































kzshz2: Intended Use: Identify who where the reviewers, what they reviewed, and if the reviewed changes have been approved to release the code for testing. Comments here should be at a highlevel, the specific comments should be present on the specific review form sheet. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. ADD DR Level Move reviewer and approval to individual checklist form Review Checklist Summary:






















































Reviewed:































YesMDD


YesSource Code


YesPolySpace









































YesIntegration Manual


YesDavinci Files








































































Comments:






























































































General Guidelines:
- The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
- New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
- To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
- .h file should be reviewed with the source file as part of the source file.





















Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)



















































Quality Check Items:




































Rationale is required for all answers of No










New baseline version name from Summary Sheet follows








Yes
Comments:



naming convention





































Project contains necessary subprojects








Yes
Comments:










































Project contains the correct version of subprojects








Yes
Comments:










































Design subproject is correct version








Yes
Comments:











































General Notes / Comments:



























































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Akilan Rathakrishnan


Review Date :

09/30/16
































Lead Peer Reviewer:


Krishna Anne


Approved by Reviewer(s):



Yes































Other Reviewer(s):










































































Sheet 3: Davinci Files






















Rev 1.28-Jun-15
Peer Review Meeting Log (Davinci Review)


























Quality Check Items:




































Rationale is required for all answers of No










Only StdDef Port types are used








Yes
Comments:










































For components not using application data types, do all








Yes
Comments:



port interface names end in PortIf and a sequence number





























































Non-program-specific components saved








Yes
Comments:




in Autosar 4.0.3 format




































*Cfg.arxml.TT: Verfied Davinci Configurator imported the








N/A
Comments:




change correctly




































*Cfg.h.TT: Verfied Davinci Configurator generates








Yes
Comments:










the configuration header(s) file correctly
kzshz2: Either a generic sandbox or a baselined integration project can be used to verify



























kzshz2: Either a generic sandbox or a baselined integration project can be used to verify
















All changed files have been compared against previous








Yes
Comments:




versions (If available)

kzshz2: Intended Use: Identify if previous version was compared and only the expected change(s) was present. This is for text files only, not binary or GUIs Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.


































Automated validation check is performed








Yes
Comments:

























































Naming conventions followed. All names should








Yes
Comments:










match DataDict.m













































Sender/Receiver port properties match DataDict.m








N/A
Comments:










file (use .m file helper tool)













































Calibration port properties match DataDict.m








N/A
Comments:










file (use .m file helper tool)













































Components using application data types:























Sender/Receiver port initialization values match







N/A
Comments:










DataDict.m file














































Calibration port initialization values match







N/A
Comments:










DataDict.m file













































Components not using application data types:























Sender/Receiver port initialization values match







Yes
Comments:










DataDict.m file and have been converted to counts






















for fixed point types














































Calibration port initialization values match







N/A
Comments:










DataDict.m file and have been converted to counts






















for fixed point types














































Mapping set and all unused items have been







N/A
Comments:










removed













































All sender/receiver port read/writes using direct








Yes
Comments:










read/writes(List justification if not)













































Runnable calling frequencies match FDD








N/A
Comments:

































DataDict.m display variables: created as








N/A
Comments:









PerInstanceMemory. Matches the FDD





































Component is correct component type








Yes
Comments:











































































General Notes / Comments:



























































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Akilan Rathakrishnan
Review Date :

09/30/16
Component Type :


Application



























Lead Peer Reviewer:


Krishna Anne
Approved by Reviewer(s):



Yes

































Other Reviewer(s):










































































Sheet 4: Source Code






















Rev 1.28-Jun-15
Peer Review Meeting Log (Source Code Review)

























Source File Name:


StHlthSigStc.c

Source File Revision:


3
Header File Name:


StHlthSigStc.h

Header File Revision:


kzshz2: Intended Use: Identify which version of the source file is being review. Rationale: Required for traceability between source code and review. Auditors will likely require this. 1

























MDD Name:

StHlthSigStc_MDD.doc

Revision:
3

























FDD/SCIR/DSR/FDR/CM Name:




ES106A_StHlthSigStc_Design

Revision:
2.3.0


























Quality Check Items:



































Rationale is required for all answers of No









Working EA4 Software Naming Convention followed:















































for variable names







Yes
Comments:

















































for constant names







N/A
Comments:

















































for function names







N/A
Comments:

















































for other names (component, memory







Yes
Comments:










mapping handles, typedefs, etc.)




































All paths assign a value to outputs, ensuring








N/A
Comments:









all outputs are initialized prior to being written





































Requirements Tracability tags in code match the requirements tracability in the FDD








N/A
Comments:









requirements tracability in the FDD





































All variables are declared at the function level.








Yes
Comments:
























Synergy version matches change history





kzshz2: Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s). Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.


Yes
Comments:



and Version Control version in file comment block





































Change log contains detailed description of changes








Yes
Comments:



and Work CR number





































Code accurately implements FDD (Document or Model)








Yes
Comments:

Functionally matches the FDD







































Verified no Compiler Errors or Warnings


KMC: Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored). Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project should be used; QAC can find compiler errors but not warnings.





Yes
Comments:
















































Component.h is included








Yes
Comments:
























All other includes are actually needed. (System includes








Yes
Comments:









only allowed in Nexteer library components)





































Software Design and Coding Standards followed:











Version: 2.1

























Code comments are clear, correct, and adequate







Yes
Comments:










and have been updated for the change: [N40] and













all other rules in the same section as rule [N40],






















plus [N75], [N12], [N23], [N33], [N37], [N38],






















[N48], [N54], [N77], [N79], [N72]














































Source file (.c and .h) comment blocks are per







Yes
Comments:










standards and contain correct information: [N41], [N42]





































Function comment blocks are per standards and







Yes
Comments:










contain correct information: [N43]





































Code formatting (indentation, placement of







Yes
Comments:










braces, etc.) is per standards: [N5], [N55], [N56],













[N57], [N58], [N59]














































Embedded constants used per standards; no







Yes
Comments:










"magic numbers": [N12]





































Memory mapping for non-RTE code







Yes
Comments:










is per standard





































All execution-order-dependent code can be







Yes
Comments:










recognized by the compiler: [N80]





































All loops have termination conditions that ensure







N/A
Comments:










finite loop iterations: [N63]





































All divides protect against divide by zero







N/A
Comments:










if needed: [N65]





































All integer division and modulus operations







N/A
Comments:










handle negative numbers correctly: [N76]





































All typecasting and fixed point arithmetic,







N/A
Comments:










including all use of fixed point macros and













timer functions, is correct and has no possibility






















of unintended overflow or underflow: [N66]














































All float-to-unsiged conversions ensure the.







N/A
Comments:










float value is non-negative: [N67]





































All conversions between signed and unsigned







N/A
Comments:










types handle msb==1 as intended: [N78]





































All pointer dereferencing protects against







Yes
Comments:










null pointer if needed: [N70]





































Component outputs are limited to the legal range







N/A
Comments:










defined in the FDD DataDict.m file : [N53]





































All code is mapped with FDD (all FDD







Yes
Comments:










subfunctions and/or model blocks identified













with code comments; all code corresponds to






















some FDD subfunction and/or model block): [N40]













































Review did not identify violations of other








Yes
Comments:









coding standard rules





































Anomaly or Design Work CR created








Yes
Comments: List Anomaly or CR numbers









for any FDD corrections needed











EA4#7781


















































General Notes / Comments:

















































































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Akilan Rathakrishnan


Review Date :

09/30/16
































Lead Peer Reviewer:


Krishna Anne


Approved by Reviewer(s):



Yes































Other Reviewer(s):










































































Sheet 5: MDD






















Rev 1.28-Jun-15
Peer Review Meeting Log (MDD Review)


























MDD Name:



StHlthSigStc_MDD.doc











MDD Revision:

3


























Source File Name:


StHlthSigStc.c



Source File Revision:


3

Source File Name:







Source File Revision:





Source File Name:















Source File Revision:






























Quality Check Items:




































Rationale is required for all answers of No










Synergy version matches document








Yes
Comments:













































Change log contains detailed description of changes








Yes
Comments:













































Changes Highlighted (for Unit Tester)








Yes
Comments:













































Diagrams have been included per MDD Guideline








Yes
Comments:











and reviewed






































All Design Exceptions and Limitations are listed








Yes
Comments:



















































Design rationale given for all global








N/A
Comments:











data not communicated through RTE ports, per














Design and Coding Standards rules [N9] and [N10].















































All implementation details that differ from the FDD are








N/A
Comments:











noted and explained in Design Rationale






































All Unit Test Considerations have been described








N/A
Comments:



















































General Notes / Comments:



























































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Akilan Rathakrishnan


Review Date :

09/30/16
































Lead Peer Reviewer:


Krishna Anne


Approved by Reviewer(s):



Yes































Other Reviewer(s):










































































Sheet 6: PolySpace






















Rev 1.28-Jun-15
Peer Review Meeting Log (QAC/PolySpace Review)


























Source File Name:



StHlthSigStc.c


Source File Revision:


3

Source File Name:



StHlthSigStc_Cfg.c


Source File Revision:


3

Source File Name:















Source File Revision:






























EA4 Static Analysis Compliance Guideline version:








01.01.00













Poly Space version:


Windows User: eg. 2013b R2013b
Polyspace sub project version:




Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 Not released

QAC version:


Windows User: eg 8.1.1-R 8.1.1-R
QAC sub project version:




Windows User: eg. TL_100A_1.1.0 TL100A_QACSuprt_1.2.0


























Quality Check Items:




































Rationale is required for all answers of No



































Contract Folder's header files are appropriate and





kzshz2: Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed. Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.


Yes
Comments:




function prototypes match the latest component version







































100% Compliance to the EA4 Static AnalysisYes
Comments:





Compliance Guideline





























Are previously added justification and deviation








Yes
Comments:





comments still appropriate






































Do all MISRA deviation comments use approved








Yes
Comments:





deviation tags






































Cyclomatic complexity and Static path count OK






Creager, Kathleen: use Browse Function Metrics, STCYC and STPTH

Yes
Comments:





for all functions in the component per Design














and Coding Standards rule [N47]

































































































General Notes / Comments:























1. Warnings under MISRA 17.1, 17.4, 21.1 , 11.4, 16.7 - All these warnings requires deviation - Open 2/15/2016


































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Akilan Rathakrishnan


Review Date :

09/30/16
































Lead Peer Reviewer:


Krishna Anne


Approved by Reviewer(s):



Yes































Other Reviewer(s):










































































Sheet 7: Integration Manual






















Rev 1.28-Jun-15
Peer Review Meeting Log (Integration Manual Review)


























Integration Manual Name:



kzshz2: Intended Use: Identify which file is being reviewed Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form. StHlthSigStc_IntegrationManual.doc

Integration Manual Revision:



kzshz2: Intended Use: Identify which version of the integration manual has been reviewed. Rationale: Required for traceability between the MDD and review. Auditors will likely require this. 4





























Quality Check Items:




































Rationale is required for all answers of No










Synergy version matches header








Yes
Comments:










































Latest template used








Yes
Comments:










































Change log contains detailed description of changes








Yes
Comments:










































Changes Highlighted (for Integrator)








Yes
Comments:











































General Notes / Comments:



























































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Akilan Rathakrishnan


Review Date :

09/30/16
































Lead Peer Reviewer:


Krishna Anne


Approved by Reviewer(s):



Yes































Other Reviewer(s):









































































3 - StHlthSigStc_IntegrationManual

Integration Manual

For

State of Health Signal Statistics

VERSION: 4.0

DATE: 27-Sep-2016

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Sl. No.DescriptionAuthorVersionDate
1Initial versionAkilan Rathakrishnan1.015-Feb-2016
2EA4#4910 fixAkilan Rathakrishnan2.028-Mar-2016
3EA4#5553 updateAkilan Rathakrishnan3.002-May-2016
4EA4#7307Akilan Rathakrishnan4.027-Sep-2016

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

3.2 Global Functions(Non RTE) to be provided to Integration Project 6

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 8

4.5 Manual Configuration Changes 8

5 Integration DATAFLOW REQUIREMENTS 9

5.1 Required Global Data Inputs 9

5.2 Required Global Data Outputs 9

5.3 Specific Include Path present 9

6 Runnable Scheduling 10

7 Memory Map REQUIREMENTS 11

7.1 Mapping 11

7.2 Usage 11

7.3 Non RTE NvM Blocks 11

7.4 RTE NvM Blocks 11

8 Compiler Settings 12

8.1 Preprocessor MACRO 12

8.2 Optimization Settings 12

9 Appendix 13

Abbrevations And Acronyms

AbbreviationDescription
DFDDesign functional diagram
MDDModule design Document
<ADD more to the table if applicable>

References

This section lists the title & version of all the documents that are referred for development of this document

Sr. No.TitleVersion
<1><FDD - <FDD ES106A_StHlthSigStc_Design>Refer Synergy subproject version

Dependencies

SWCs

ModuleRequired Feature
NoneN/A

Note : Referencing the external components should be avoided in most cases. Only in unavoidable circumstance external components should be referred. Developer should track the references.

Global Functions(Non RTE) to be provided to Integration Project

See section 6. Please note the server runnables listed can be used as needed in the integration project and can be called via the RTE or outside of the RTE as required

Non-Trusted FunctionParametersNotes
NONTRUSTED_NtWrapS_StHlthSigStc_UpdNvmPimThis function shall be defined as a non-trusted function call to the application that StHlthSigStc is integrated.
NONTRUSTED_NtWrapS_StHlthSigStc_ClrDataSampleThis function shall be defined as a non-trusted function call to the application that StHlthSigStc is integrated.
NONTRUSTED_NtWrapS_StHlthSigStc_UpdDataSampleThis function shall be defined as a non-trusted function call to the application that StHlthSigStc is integrated.

Configuration REQUIREMeNTS

Build Time Config

ModulesNotes
None

Configuration Files to be provided by Integration Project

StHlthSigStc_Cfg.c

StHlthSigStc_Cfg.h

Note: Include “StHlthSigStc_Cfg.h” in the “Rte_UserTypes.h” file since user defined typedefs are generated in this file.

Da Vinci Parameter Configuration Changes

Following configurations shall be made in DaVinci configurator for the component.

There are three containers that need to be instantiated for this components configuration.

  1. StHlthSigStcApplicationConfigs : OS application in which this component is scheduled to run shall be configured in this container.

Parameter NameParameter Value
OS Application ReferenceApplication in which ES106A scheduled
  1. StHlthSigStcCrConfigLists: List of CRC constants that are need to be checked for NvM validation shall be configured in this container. Each CRC constant shall have one entry.

Below table indicates list of CRC values currently considered.

Parameter NameParameter Value
StHlthSigStcCrcStartSymbolApplication CRC symbol name
  1. StHlthSigStcSignalLists: This list shall have one entry for every monitored signal.

Following set of information shall be configured for every signal:

  1. Singal Name: Signal name of the State of Health signal (mentioned in the below table).

  2. Task Id: Task id of the task in which the periodic(s) from the FDD, mentioned against respective signal in the below table, is scheduled.

  3. Loop time: Loop time of the task with 1 micro second resolution.

Signal NameFDD
CtrlrTStHlthES210A_EcuTMeas
OutpAssiStHlthES259A_BattVltgCorrln
DigTqSnsrAStHlthES229A_HwTqCorrln
DigTqSnsrBStHlthES229A_HwTqCorrln
DigTqIdptSigStHlthES229A_HwTqCorrln
DutyCycStHlthSF009A_DutyCycThermProtn
EotImpctStHlthSF011A_EotLrng
MotPosStHlthES241A_MotAg2Meas
AbsltMotPosABDifStHlthES249A_MotAgCorrln
AbsltMotPosACDifStHlthES249A_MotAgCorrln
AbsltMotPosBCDifStHlthES249A_MotAgCorrln
CurrMotSumABCStHlthES209A_CurrMeasCorrln
CurrMotSumDEFStHlthES209A_CurrMeasCorrln
PhaAStHlthES320A_MotDrvDiagc
PhaBStHlthES320A_MotDrvDiagc
PhaCStHlthES320A_MotDrvDiagc
PhaDStHlthES320A_MotDrvDiagc
PhaEStHlthES320A_MotDrvDiagc
PhaEStHlthES320A_MotDrvDiagc
RamEccSngBitCorrnStHlthCM103A_RamMem
FricEstimnStHlthSF007A_SysFricLrng
WhlImbMaxCmpStHlthSF015A_WhlImbRejctn

DaVinci Interrupt Configuration Changes

ISR NameVIM #Priority DependencyNotes
N/A

Manual Configuration Changes

ConstantNotesSWC
N/A

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file

Required Global Data Outputs

Refer DataDict.m file

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

InitScheduling RequirementsTrigger
StHlthSigStcInit1Invoked by RTE during InitRTE
RunnableScheduling RequirementsTrigger
ClrSigStcHlthData_OperServer RunnableClient Call
GetSigStcHlthData_OperServer RunnableClient Call
StHlthStcPwrDwn_OperServer RunnableClient Call
UpdStHlthStcData_OperServer RunnableClient Call
NONTRUSTED_NtWrapS_StHlthSigStc_ClrDataSample

Non-Tusted function definition

(Index: NtWrapS_StHlthSigStc_ClrDataSample)

On Event
NONTRUSTED_NtWrapS_StHlthSigStc_UpdNvmPim

Non-Tusted function definition

(Index: NtWrapS_StHlthSigStc_UpdNvmPim)

On Event
NONTRUSTED_NtWrapS_StHlthSigStc_UpdDataSample

Non-Tusted function definition

(Index: NtWrapS_StHlthSigStc_UpdDataSample)

On Event

Memory Map REQUIREMENTS

Mapping

Memory SectionContentsNotes
None

* Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.

Usage

FeatureRAMROM
None

Table 1: ARM Cortex R4 Memory Usage

Non RTE NvM Blocks

Block Name
None

Note : Size of the NVM block if configured in developer

RTE NvM Blocks

Block Name
SigStcHistDataAry

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

<This section is for appendix>

4 - StHlthSigStc_MDD

Module Design Document

For

State of Health Signal Statistics

Sep 27, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USAChange History

Sl. No.DescriptionAuthorVersionDate
1Initial VersionAkilan Rathakrishnan1.015-Feb-2016
2Updated for EA4#5553Akilan Rathakrishnan2.004-May-2016
3Updated for EA4#7307Akilan Rathakrishnan3.027-Sep-2016

Table of Contents

1 StHlthSignStc High-Level Description 5

2 Design details of software module 6

Graphical representation of StHlthSigStc 6

Data Flow Diagram 6

2.1.1 Component level DFD 6

2.1.2 Function level DFD 6

3 Variable Data Dictionary 7

3.1 User defined typedef definition/declaration 7

3.2 Variable definition for enumerated types 7

4 Constant Data Dictionary 8

Program (fixed) Constants 8

4.1.1 Embedded Constants 8

4.1.1.2 Global 8

4.1.2 Module specific Lookup Tables Constants 8

5 Software Module Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Initialization Functions: StHlthSigStcInit1 9

5.1.2 PERIODIC FUNCTIONS 9

5.1.3 Interrupt Functions 9

5.1.4 Server Runnable Functions 9

5.1.4.1 ClrSigStcHlthData_Oper 9

5.1.4.2 GetSigStcHlthData_Oper 9

5.1.4.3 StHlthStcPwrDwn_Oper 9

5.1.4.4 UpdStHlthStcData_Oper 9

5.1.5 Module Internal (Local) Functions 9

5.1.5.1 Local Function #1 9

5.1.5.1.1 Description 9

5.1.5.2 Local Function #2 9

5.1.5.2.1 Description 10

5.1.5.3 Local Function #3 10

5.1.5.3.1 Description 10

5.1.5.4 Local Function #4 10

5.1.5.4.1 Description 10

5.1.6 Transition Functions 10

5.1.7 Global Function/Macro Definitions 10

5.1.7.1 Global Function #1 10

5.1.7.1.1 Description 10

5.1.7.2 Global Function #2 11

5.1.7.2.1 Description 11

5.1.7.3 Global Function #3 11

5.1.7.3.1 Description 11

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Appendix A Abbreviations and Acronyms 14

Appendix B Glossary 15

Appendix C References 16

StHlthSignStc High-Level Description

This component shall collect State of Health data signals from other component(s) and shall compute following statistical values for each signal: Minimum, Maximum, Average and Life Cycle Sample counter. This component shall provide statistical data for ignition cycle and for life cycle for each signal upon request.

Design details of software module

See FDD.

Graphical representation of StHlthSigStc

Data Flow Diagram

See FDD.

Component level DFD

See FDD.

Function level DFD

See FDD.

Variable Data Dictionary

User defined typedef definition/declaration

<This section documents any user types uniquely used for the module.>

Typedef NameElement NameUser Defined Type

Legal Range

(min)

Legal Range

(max)

Ary1D_u8_ StHlthSigStc1Arrayuint8065535
Ary1D_u32_ StHlthSigStc1Arrayuint32065535
StHlthSigStcPrmRec1GetStHlthDataOperuint8 (*GetDataOper)(void )04294967295
SamplePerSecuint16065535
TaskRefTaskType0255
RamStorgOffsuint80255
NvmStorgOffsuint80255
StHlthSigStcCrcAdrRec1* CrcStrtAdruint3204294967295
StHlthSigStcPrmRec1*SigPrmStHlthSigStcPrmRec104294967295
*CrcAdrStHlthSigStcCrcAdrRec104294967295

Ary1D_u8_StHlthSigStc1 – Typedef for Ram buffer where State of Health Statistical data is kept for the current Ignition cycle. Size of this array is configurable.

Ary1D_u32_ StHlthSigStc1 – Typedef for Ignition cycle sample counter. Size of this array is configurable.

Variable definition for enumerated types

Enum NameElement NameValue
See DataDict.m file

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant NameResolutionUnitsValue
See DataDict.m file
CRCBUFSIZE_CNT_U081Cnt(WORDSIZE_CNT_U08*NROFCRCAREA_CNT_U08)

* Also see see FDD ES106A_StHlthSigStc_DataDict.m file

Global

<This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application>

Constant Name
See DataDict.m file

Module specific Lookup Tables Constants

<(This is for lookup tables (arrays) with fixed values, same name as other tables)>

Constant NameResolutionValueSoftware Segment
StHlthSigStcCfgRecInstStHlthSigStcCfgRec1ConfiguredStHlthSigStc_CONST

Software Module Implementation

Sub-Module Functions

None

Initialization Functions: StHlthSigStcInit1

See DataDict.m file and model. This function exists in “StHlthSigStc.c” file.

PERIODIC FUNCTIONS

None

Interrupt Functions

None

Server Runnable Functions

ClrSigStcHlthData_Oper

See DataDict.m file and model. This function exists in “StHlthSigStc.c” file.

GetSigStcHlthData_Oper

See DataDict.m file and model. This function exists in “StHlthSigStc.c” file.

StHlthStcPwrDwn_Oper

See DataDict.m file and model. This function exists in “StHlthSigStc.c” file.

UpdStHlthStcData_Oper

See DataDict.m file and model. This function exists in “StHlthSigStc.c” file.

Module Internal (Local) Functions

Local Function #1

Function NameStHlthSigStc_ClrDataSampleTypeMinMax
Arguments PassedTarSel_Uls_T_loglbooleanFALSETRUE
Return ValueNoneN/AN/AN/A

Description

This function implements “StHlthStcPwrDwn” function in the FDD.

Local Function #2

Function NameStHlthSigStc_GetSigStHlthDataTypeMinMax
Arguments PassedSigId_Uls_T_enumStHlthMonSig3021
TarAdruint8*0x00000000xFFFFFFFF
Return ValueNoneN/AN/AN/A

Description

This function implements “GetSigStcHlthData” function in the FDD.

Local Function #3

Function NameStHlthSigStc_UpdNvmPimTypeMinMax
Arguments PassedNvmPim_Ptr_T_u08uint8*0x00000000xFFFFFFFF
NvmMaxVal_Uls_T_u08uint80100
NvmMinVal_Uls_T_u08uint80100
NvmAvrgVal_Uls_T_u08uint80100
NvmSampleCnt_Uls_T_u32Uint320Max of u32
Return ValueNoneN/AN/AN/A

Description

This function implements “Update Nvm” function in the FDD.

Local Function #4

Function NameStHlthSigStc_UpdDataSampleTypeMinMax
Arguments PassedTaskRef_Uls_T_u08uint80255
Return ValueNoneN/AN/AN/A

Description

This function implements “Update Nvm” function in the FDD.

Transition Functions

None.

Global Function/Macro Definitions

Global Function #1

Function NameNONTRUSTED_NtWrapS_StHlthSigStc_UpdDataSampleTypeMinMax
Arguments PassedFunctionIndexNonTrustedFunctionIndexType065535
FunctionParamsNonTrustedFunctionParameterRefType00xFFFFFF
Return Valuevoid

Description

Implements Nontrusted function wrapper for UpdDataSample. This will be called from UpdStHlthStcData_Oper upon client invocation.

Global Function #2

Function NameNONTRUSTED_NtWrapS_StHlthSigStc_UpdNvmPimTypeMinMax
Arguments PassedFunctionIndexNonTrustedFunctionIndexType065535
FunctionParamsNonTrustedFunctionParameterRefType00xFFFFFF
Return Valuevoid

Description

Implements Nontrusted function wrapper for UpdNvmPim. This will be called from StHlthStcPwrDwn_Oper upon client invocation.

Global Function #3

Function NameNONTRUSTED_NtWrapS_StHlthSigStc_ClrDataSampleTypeMinMax
Arguments PassedFunctionIndexNonTrustedFunctionIndexType065535
FunctionParamsNonTrustedFunctionParameterRefType00xFFFFFF
Return Valuevoid

Description

Implements Nontrusted function wrapper for UpdNvmPim. This will be called from ClrSigStcHlthData_Oper upon client invocation.

Known Limitations with Design

  1. Following constants are not used in the implementation even though they defined in the .m file. It is only used for the purpose of model simulation.

  1. SHIFTFAC16_ULS_U08

  2. SHIFTFAC24_ULS_U08

  3. SHIFTFAC8_ULS_U08

  1. Implementation uses different name for following PIM variables that are defined in .m file:

    1. SigStcPrmInst

    2. CrcInst

UNIT TEST CONSIDERATION

Config files in the contract folder are for a test project with sample configurations for two monitored signals CtrlrTStHlth and OutpAssiStHlth.

Abbreviations and Acronyms

Abbreviation or AcronymDescription
DFDDesign functional diagram
MDDModule design Document
FDDFunctional Design Document

Glossary

Note: Terms and definitions from the source “Nexteer Automotive” take precedence over all other definitions of the same term. Terms and definitions from the source “Nexteer Automotive” are formulated from multiple sources, including the following:

  • ISO 9000

  • ISO/IEC 12207

  • ISO/IEC 15504

  • Automotive SPICE® Process Reference Model (PRM)

  • Automotive SPICE® Process Assessment Model (PAM)

  • ISO/IEC 15288

  • ISO 26262

  • IEEE Standards

  • SWEBOK

  • PMBOK

  • Existing Nexteer Automotive documentation

TermDefinitionSource
MDDModule Design Document
DFDData Flow Diagram

References

Ref. #TitleVersion
1AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)v1.3.0 R4.0 Rev 2
2MDD GuidelineEA4 01.00.00
3Software Naming Conventions.doc1.0
4Software Design and Coding Standards.doc2.0
5FDD: ES106A_StHlthSigStc_DesignSee Synergy subproject version