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

Return to the regular view of this page.

Component Implementation

Component Implementation

Component Documentation

1 - DiagcMgr Review

Overview

Summary Sheet
Synergy Project
DiagcMgr
PolySpace

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. ES101A_DiagcMgr_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. ES101A_DiagcMgr_Impl_4.3.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. Spandana Balani
Work CR ID:


EA4#7865





























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:































N/AMDD


YesSource Code


YesPolySpace









































N/AIntegration Manual


N/ADavinci 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:

Spandana Balani


Review Date :

10/05/16
































Lead Peer Reviewer:


Avinash James


Approved by Reviewer(s):



Yes































Other Reviewer(s):









































































Sheet 3: DiagcMgr






















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

























Source File Name:


DiagcMgr.c

Source File Revision:


14
Header File Name:


StaticType.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. 2
Header File Name:


Private.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. 6
Header File Name:





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.
Header File Name:





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.
MDD Name:

DiagcMgr_MDD.doc

Revision:
6
FDD/SCIR/DSR/FDR/CM Name:




ES101_DiagcMgr_Design

Revision:
4.4.0


























Quality Check Items:



































Rationale is required for all answers of No









Working EA4 Software Naming Convention followed:















































for variable names







N/A
Comments:

















































for constant names







N/A
Comments:

















































for function names







N/A
Comments:

















































for other names (component, memory







N/A
Comments:










mapping handles, typedefs, etc.)




































All paths assign a value to outputs, ensuring








Yes
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.








N/A
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:






















































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







N/A
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







N/A
Comments:










is per standard





































All execution-order-dependent code can be







N/A
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







N/A
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








N/A
Comments: List Anomaly or CR numbers









for any FDD corrections needed































































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:

Spandana Balani


Review Date :

10/05/16
































Lead Peer Reviewer:


Avinash James


Approved by Reviewer(s):



Yes































Other Reviewer(s):









































































Sheet 4: PolySpace






















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


























Source File Name:


DiagcMgr.cSource File Revision:


14

Source File Name:


DiagMgrNonRte.cSource File Revision:


4

Source File Name:



Source File Revision:






























EA4 Static Analysis Compliance Guideline version:







01.01.00







Poly Space version:


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




Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 TL108A_PolyspaceSuprt_1.0.0

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

No
Comments:





for all functions in the component per Design










see comments below


and Coding Standards rule [N47]

































































































General Notes / Comments:























DiagcMgrPer2, DiagcMgrPwrDwn exceed the complexity and path count limits defined in the Coding Standards. Due to time constraint, this is not fixed in current version


































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:

Spandana Balani


Review Date :

10/05/16
































Lead Peer Reviewer:


Avinash James


Approved by Reviewer(s):



Yes































Other Reviewer(s):









































































2 - DiagcMgr_IntegrationManual

Integration Manual

For

Diagnostic Manager

VERSION: 4.0

DATE: 22-JUN-2016

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

Location: The official version of this document is stored in the Nexteer Configuration Management System.

Revision History

Sl. No.DescriptionAuthorVersionDate
1Initial versionSpandana Balani1.023-Apr-2015
2Updated to FDD version 2Spandana Balani2.011-Mar-2016
3Updated to FDD version 3Spandana balani3.022-APR-2016
4Updated to FDD version 4Spandana balani4.022-Jun-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 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><MDD Guidelines>Process 04.02.01
<2><Software Naming Conventions>Process 04.02.01
<3><Coding standards>Process 04.02.01
<4>FDD – ES101A Diagnostic ManagerSee Synergy Subproject version
<Add if more available>

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

DiagcMgrPwrDwn() –Non RTE Server Runnable, called from BswM. It copies the appropriate information for upto 20 NTCs from Application NtcInfoArys and stores it to Nvm PIM. And, calls "SetRamBlockSts".

RestoreNtcFltAryDft() , RestoreSnpshtAryDft() – Non RTE Server Runnables, called from Nvm Manager if the Nvm Data is corrupted.

Configuration REQUIREMeNTS

Only proxies components that have active NTCs should be brought into developer worksace. Stub needs to be integrated for connection to the core's client ports for all the un-implemented applications. Proper .gpj fles needs to be selected for inclusion in the project’s .gpj file.

The Integrator must configure one and only one “/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DTCEnaCndn” for configured DTC in the DEM

Build Time Config.

ModulesNotes
None

Configuration Files to be provided by Integration Project

DiagcMgr_Cfg.h

DiagcMgr_Cfg.c

Note: Include “DiagcMgr_Cfg.h” in the “Rte_UserTypes.h” header file

Da Vinci Parameter Configuration Changes

ParameterNotesSWC
/Nexteer/EcucDefs_DiagcMgr/DiagcMgrConfiguration of the DiagcMgr moduleDiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNRContainer with NTC number propertiesDiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR/NTCOsApplicationRefNTC Os Application. This defines the application corresponding to a particular NTCDiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR/DebounceSet to true if NTC is type debounceDiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DTCEnaCndnContainer with DTC ENABLE CriteriaDiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DTCEnaCndn/DTCThis defines the DEM DTC Class.DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DTCEnaCndn/Bit_X1Set to true if Enable Condition for Bit X1 is applicable to configured DTCDiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DTCEnaCndn/DiagcMgrDTCIdxValue represents index value DiagcMgr uses internally for NTC mapping to DTCs to the Event ID that the Dem identifies for a particular DTCDiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DiagcMgrGeneralContainer with General DiagcMgr configurationDiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DiagcMgrGeneral/DIAGCMGR_DEMCHK

Set to true to enable DET consistency check between DEM and DiagcMgr DTC configuration.

This check assumes the Dem will generate the constant table named” Dem_C_DtcTable” that will be sized to the configured DTCs + 1. If this assumption is not true, turn this parameter OFF.

DiagcMgr

1 Note: X = _0 to 15

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
DiagcMgProxyApplXInit1Init function needs to run before any other init function that is trying to set an NTC and it therefore should be called early on in the initialization tasks.Rte_Init
RunnableScheduling RequirementsTrigger
DiagcMgrPer1NoneRTE 2ms Task
DiagcMgrPer2NoneRTE 100ms Task
ClrAllDiagc_OperServer RunnableClient Call
ClrSnpshtData_OperServer RunnableClient Call
DiagcMgrIninCore_OperServer RunnableInternal to DiagcMgr2
GetNtcActvCore_OperServer RunnableInternal to DiagcMgr2
GetNtcQlfrStsCore_OperServer RunnableInternal to DiagcMgr2
GetNtcStsCore_OperServer RunnableInternal to DiagcMgr2
ReadNtcFltAryCore_OperServer RunnableClient Call
ReadNtcInfoAndDebCntr_OperServer RunnableClient Call
ReadSnpshtData_OperServer RunnableClient Call
SetNtcStsCore_OperServer RunnableInternal to DiagcMgr2
DiagcMgrPwrDwnNon RTE Server RunnableClient Call
RestoreNtcFltAryDftNon RTE Server RunnableClient Call
RestoreSnpshtAryDftNon RTE Server RunnableClient Call
DiagcMgrProxyApplXInit11On InitRTE Init
DiagcMgrProxyApplXPer11NoneRTE 10ms Task
GetDiagcDataApplX_Oper1Server RunnableInternal to DiagcMgr2
GetNtcActvX_Oper1,3Server RunnableClient Call
GetNtcDebCntrAppl0_Oper1Server RunnableClient Call
GetNtcInfoApplX_Oper1Server RunnableInternal to DiagcMgr2
GetNtcQlfrStsX_Oper1,3Server RunnableClient Call
GetNtcStsX_Oper1,3Server RunnableClient Call
SetNtcStsX_Oper1,3Server RunnableClient Call
UpdDtcEnaCdn4Non RTE Server RunnableClient Call

Note: 1 – X in the Runnable name represent the application number. There 11 applications varying from 0 to 10 and each application has a ProxyDiagcMgr component. One set of all these server runnables exist in each proxy component.

2 – Runnables with trigger ‘Internal to DiagcMgr’ are local to DiagcMgr main component and 11 proxy components, other components will not have access to these functions. Whenever a component inside an application calls one of the server runnables, the ProxyDiagcMgr of that application will make a client call to the DiagcMgr main component.

3 – These Server Runnables must be defined with “can be invoked concurrently” enabled in Developer.

4 – This function is assumed to be called by bswm providing periodic updates of DTC enable condition.

DTC enable conditions should be defined by the fault code requirement.

Memory Map REQUIREMENTS

Mapping

Memory SectionContentsNotes
< Memory mapping Info>*

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

Usage

FeatureRAMROM
<Memmap usuage info>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

*See DataDict.m

This component assumes that the integrator will keep the default NvM block name and the Block ID name will be "NvMConf_NvMBlockDescriptor_Rte_NvmBlock_DiagcMgr_DiagcMgrNtcFltAry”.

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

<This section is for appendix>

3 - DiagcMgr_MDD

Module Design Document

For

Diagnostic Manager

VERSION: 5.0

DATE: 26-SEP-2016

Prepared By:

Spandana Balani

Location: The official version of this document is stored in the Nexteer Configuration Management System.

Revision History

Sl. No.DescriptionAuthorVersionDate
1Initial VersionSB1.023-Apr-2015
2Added to Design Limitations sectionKMC2.003-Jun-2015
3ES101A_DiagcMgr_Design version 2 implementationSB3.011-Mar-2016
4ES101A_DiagcMgr_Design version 3 implementationSB4.019-Apr-2016
5ES101A_DiagcMgr_Design version 4 implementationSB5.022-Jun-2016
6Added DETs to “SetNtcStsCore_Oper” server runnablesSB6.026-Sep-2016

Table of Contents

1 Abbrevations And Acronyms 6

2 References 7

3 DiagcMgr & High-Level Description 8

4 Design details of software module 9

4.1 Graphical representation of Diagcmgr 9

4.2 Data Flow Diagram 9

4.2.1 Module level DFD 9

4.2.2 Sub-Module level DFD 9

4.3 COMPONENT FLOW DIAGRAM 10

5 Variable Data Dictionary 11

5.1 User defined typedef definition/declaration 11

5.2 Variable definition for enumerated types 11

6 Constant Data Dictionary 12

6.1 Program(fixed) Constants 12

6.1.1 Embedded Constants 12

6.1.1.1 Local 12

6.1.1.2 Global 12

6.1.2 Module specific Lookup Tables Constants 12

7 Software Module Implementation 13

7.1 Sub-Module Functions 13

7.1.1 Initialization Functions 13

7.1.2 PERIODIC FUNCTIONS 13

7.1.2.1 Per: diagcmgrPer1 13

7.1.2.1.1 Design Rationale 13

7.1.2.1.2 Store Module Inputs to Local copies 13

7.1.2.1.3 (Processing of function)……… 13

7.1.2.1.4 Store Local copy of outputs into Module Outputs 13

7.1.2.2 Per: diagcmgrPer2 13

7.1.2.2.1 Design Rationale 14

7.1.2.2.2 Store Module Inputs to Local copies 15

7.1.2.2.3 (Processing of function)……… 15

7.1.2.2.4 Store Local copy of outputs into Module Outputs 15

7.1.3 Interrupt Functions 15

7.1.4 Server Runnable Functions 16

7.1.4.1 ClrAllDiagc_Oper 16

7.1.4.2 ClrSnpshtData_Oper 16

7.1.4.3 DiagcMgrIninCore_Oper 16

7.1.4.4 DiagcMgrPwrDwN 17

7.1.4.4.1 Design Rationale 18

7.1.4.5 UpdDtcEnaCdn 18

7.1.4.5.1 Design Rationale 18

7.1.4.6 GetNtcActvCORE_Oper 19

7.1.4.7 GetNtcQlfrStsCORE_Oper 19

7.1.4.8 GetNtcStsCORE_Oper 19

7.1.4.9 ReadNtcFltAry_Oper 19

7.1.4.9.1 Design Rationale 19

7.1.4.10 ReadNtcInfoAndDebCntr_Oper 19

7.1.4.10.1 Design Rationale 19

7.1.4.11 ReadSnpshtData_Oper 19

7.1.4.12 SetNtcStsCORE_Oper 19

7.1.4.13 RestoreNtcFltAryDft 19

7.1.4.14 RestoreSnpshtAryDft 20

7.1.5 Local Function/Macro Definitions 20

7.1.5.1 Local Function #1 20

7.1.5.2 Description 20

7.1.5.3 Local Function #2 20

7.1.5.4 Description 20

7.1.6 GLObAL Function/Macro Definitions 20

7.1.6.1 GLObAL Function #1 20

7.1.6.1.1 Description 21

7.1.6.2 GLObAL Function #2 21

7.1.6.2.1 Description 21

7.1.6.3 GLObAL Function #3 21

7.1.6.3.1 Description 21

7.1.6.4 GLObAL Function #4 21

7.1.6.5 Description 21

7.1.6.6 GLObAL Function #5 21

7.1.6.7 Description 22

7.1.6.8 GLObAL Function #6 22

7.1.6.9 Description 22

7.1.6.10 GLObAL Function #7 22

7.1.6.11 Description 22

7.1.6.12 GLObAL Function #8 22

7.1.6.13 Description 22

7.1.7 TRANSIENT FUNCTIONS 22

8 Known Limitations With Design 23

9 UNIT TEST CONSIDERATION 24

10 Appendix 25

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><MDD Guidelines>Process 04.02.01
<2><Software Naming Conventions>Process 04.02.01
<3><Coding standards>Process 04.02.01
<4>FDD – ES101A Diagnostic ManagerSee Synergy Subproject version
<Add if more available>

DiagcMgr & High-Level Description

Design details of software module

Graphical representation of Diagcmgr

Data Flow Diagram

Module level DFD

N/A

Sub-Module level DFD

N/A

COMPONENT FLOW DIAGRAM

N/A

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)

NtcMapRec1ApplIdxUint8010
NtcInfoIdxuint80255
NtcInfoRec4NtcStInfoUint8
StsUint8
AgiCntrUint8
Ary1D_NtcInfoRec4NtcInfoRec4[]1
Ary1D_NtcInfoRec4_DiagcMgrProxyApplX3NtcInfoRec4[]1
Ary1D_s16_DiagcMgrProxyApplX3Sint16[]2

1 – Array of NtcInfoRec4

2 – Array of sint16

3 – One for each Application configured with NTCs

For example – Application 6 and 10 have NTCs then - Ary1D_NtcInfoRec4_DiagcMgrProxyAppl6, Ary1D_NtcInfoRec4_DiagcMgrProxyAppl10, Ary1D_s16_DiagcMgrProxyAppl6, Ary1D_s16_DiagcMgrProxyAppl10 would exist with configured sizes.

Variable definition for enumerated types

Enum NameElement NameValue
See DataDict.m file

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

< All program specific constants will be defined in detail >

Local

Constant NameResolutionUnitsValue
See DataDict.m file
IMDTSHTDWNFLT_CNT_U321Counts13
CTRLDSHTDWNFLT_CNT_U321Counts14
INFOONLYFLT_CNT_U321Counts15
TOTNROFDTC_CNT_U0841CountsConfigured

4 - Number of DTCs for that program.

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
DiagcMgrNtcMap_Cnt_rec[512]NtcMapRec1ConfiguredDiagcMgr_START_SEC_CODE
NtcNrAryApplX_Cnt_u16[Configured]51ConfiguredDiagcMgr_START_SEC_CODE
DtcEnaMask[Configured]61ConfiguredDiagcMgr_START_SEC_CODE
DemDtcEveIdMap[Configured]61ConfiguredDiagcMgr_START_SEC_CODE
FltRespRampTbl_Uls_f32[13]Single Precision Float{0.1F,0.125F,0.1428F,0.1667F,0.2F,0.25F,0.333F,0.5F,1.0F,2.0F,3.333F,10.0F,500.0F}DiagcMgr_START_SEC_CODE

5 - One for each Application configured with NTCs.

6 - Variable Length (TOTNROFDTC_CNT_U08 + 1) for each build/program depending on the Number of DTCs

for that program.

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

None

PERIODIC FUNCTIONS

(Note: For multiple periodic functions, insert new headers at the “Header 2” level – subset of “7.1.2 Periodic Functions” and follow the same sub-section design shown below). If none required, place the text “None”)>

Per: diagcmgrPer1

This function exists in “DiagcMgr.c” file.

Design Rationale

“Rte_Call_GetDiagcDataApplX_Oper” for each application(X) is called based on conditional compile using constants generated in DiagcMgr_Cfg_private.h

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

Per: diagcmgrPer2

This function exists in “DiagcMgr.c” file.

Design Rationale

“Rte_Call_GetDiagcDataApplX_Oper” for each application(X) is called based on conditional compile using constants generated in DiagcMgr_Cfg_private.h

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

Interrupt Functions

None

Server Runnable Functions

(Note: For multiple periodic functions, insert new headers at the “Header 2” level – subset of “7.1.2 Periodic Functions” and follow the same sub-section design shown below). If none required, place the text “None”)>

ClrAllDiagc_Oper

See DataDict.m file and model

This function exists in “DiagcMgr.c” file.

ClrSnpshtData_Oper

See DataDict.m file and model

This function exists in “DiagcMgr.c” file.

DiagcMgrIninCore_Oper

See DataDict.m file and modelThis function exists in “DiagcMgr.c” file.

DiagcMgrPwrDwN

See DataDict.m file and model

This function exists in “DiagcMgrNonRte.c” file.

Design Rationale

“GetNtcInfoApplX_Oper” for each application(X) is called based on conditional compile using constants generated in DiagcMgr_Cfg_private.h.

“NvMConf_NvMBlockDescriptor_Rte_NvmBlock_DiagcMgr_DiagcMgrNtcFltAry” is used instead of BlockID Number in “NvMProxy_SetRamBlockStatus” call so that the Integrator doesn’t have to configure the DiagcMgr to know about the Nvm block Ids.

UpdDtcEnaCdn

See DataDict.m file and model

This function exists in “DiagcMgrNonRte.c” file.

Design Rationale

“GetNtcInfoApplX_Oper” for each application(X) is called based on conditional compile using constants generated in DiagcMgr_Cfg_private.h.

GetNtcActvCORE_Oper

See DataDict.m file and model

This function exists in “DiagcMgr.c” file.

GetNtcQlfrStsCORE_Oper

See DataDict.m file and model

This function exists in “DiagcMgr.c” file.

GetNtcStsCORE_Oper

See DataDict.m file and model

This function exists in “DiagcMgr.c” file.

ReadNtcFltAry_Oper

See DataDict.m file and model

This function exists in “DiagcMgr.c” file.

Design Rationale

“GetNtcInfoApplX_Oper” for each application(X) is called based on conditional compile using constants generated in DiagcMgr_Cfg_private.h

ReadNtcInfoAndDebCntr_Oper

See DataDict.m file and model

This function exists in “DiagcMgr.c” file.

Design Rationale

“GetNtcDebCntrApplX” and “GetNtcInfoApplX_Oper” for each application(X) is called based on conditional compile using constants generated in DiagcMgr_Cfg_private.h

ReadSnpshtData_Oper

See DataDict.m file and model

This function exists in “DiagcMgr.c” file.

SetNtcStsCORE_Oper

See DataDict.m file and model

This function exists in “DiagcMgr.c” file.

RestoreNtcFltAryDft

See DataDict.m file and model

This function exists in “DiagcMgrNonRte.c” file.

RestoreSnpshtAryDft

See DataDict.m file and model

This function exists in “DiagcMgrNonRte.c” file.

Local Function/Macro Definitions

<If these are numerous and defined in a separate source file then reference the source file only.>

Local Function #1

Function NameProcRampRespTypeMinMax
Arguments PassedNtcNr_Cnt_T_u16uint160511
DiagcData_T_recDiagcDataRec1065535
ProxySetNtcData_T_recDiagcDataRec1065535
Return ValueN/A

Description

Refer ‘ProcessRampResponse and DiagcSts’ block in Simulink model

This function exists in “DiagcMgr.c” file.

Local Function #2

Function NameUpdSnpshtDataTypeMinMax
Arguments PassedRegInBRAMDAT1_Cnt_T_u32uint3204294967295
HwTq_Cnt_T_s5p10sint16-1010
MotTqCmdMrfScad_Cnt_T_s5p10sint16-8.88.8
IgnCntr_Cnt_T_u32uint3204294967295
BrdgVltg_Cnt_T_u6p10uint16626.5
EcuTFild_Cnt_T_s8p7sint16-50150
NtcNr_Cnt_T_u16NtcNr1NTCNR_0X001NTCNR_0X1FF
NtcStInfo_Cnt_T_u08uint80255
SysSt_Cnt_T_enumSysSt1SYSST_DISYSST_WRMININ
VehSpd_Cnt_T_u9p7Uint160511
Return ValueN/A

Description

Refer ‘UpdSnpshtData’ block in Simulink model

This function exists in “DiagcMgr.c” file

GLObAL Function/Macro Definitions

:All the global functions described below are declared in DiagcMgr_private.h and are intended to be used only by DiagcMgr and the DiagcMgrProxyApplX components.These functions exist in “DiagcMgr_private.c” file.

GLObAL Function #1

Function NameProcessDiagStsTypeMinMax
Arguments PassedFltRsp_Cnt_T_u32uint3204294967295
DiagStsX_Cnt_T_u16uint16065535
Return ValueN/A

Description

Refer to “ES101A_DiagcMgr/DiagcMgr/SetNtcStsCore/NtcNr is Valid/Diagnostics Not Inhibited/NtcEnabled/NTCSTS_PREFAILD/Update NtcInfoSts, DebCntr and Process RampRate/DebCntr = MAXDEBCNTRVAL_CNT_S16/ProcessRampResponse and DiagcSts/ControlledShutdown Fault/ProcessDiagcSts” Simulink path in the FDD.

GLObAL Function #2

Function NameProcProxyRampRespTypeMinMax
Arguments PassedNtcNr_Cnt_T_u16uint160511
ProxyDiagcData_T_recDiagcDataRec1065535
Return ValueN/A

Description

Refer ‘ProcessRampResponse and DiagcSts’ block in Simulink path ” ES101A_DiagcMgrProxyX/DiagcMgrProxyApplX/DiagcMgrProxyApplXPer1/Update the DiagcSts/For Number of NTCs/Update DiagcSts and Ramp Response/Update Latest Values/ProcessRampResponse”

GLObAL Function #3

Function NameDiagcMgrSetBits_u16TypeMinMax
Arguments PassedDatauint160511
BitMaskUint160511
Return ValueDataUint160511

Description

This function will set bits based on the passed BitMask for a uint16 datatype.

GLObAL Function #4

Function NameDiagcMgrSetBits_u08TypeMinMax
Arguments PassedDataUint80255
BitMaskUint80255
Return ValueDataUint80255

Description

This function will set bits based on the passed BitMask for a uint8 datatype

GLObAL Function #5

Function NameDiagcMgrClrBits_u08TypeMinMax
Arguments PassedDataUint80255
BitMaskUint80255
Return ValueDataUint80255

Description

This function will clear bits based on the passed BitMask for a uint8 datatype

GLObAL Function #6

Function NameDiagcMgrReadBit_u08TypeMinMax
Arguments PassedDataUint80255
BitMaskUint80255
Return ValueDataUint80255

Description

This function will return TRUE if any bits are set based on the passed BitMask for a uint8 datatype

GLObAL Function #7

Function NameDiagcMgrReadBit_u16TypeMinMax
Arguments PassedDatauint160511
BitMaskUint160511
Return ValueDataUint160511

Description

This function will return TRUE if any bits are set based on the passed BitMask for a uint16 datatype

GLObAL Function #8

Function NameDiagcMgrReadBit_u32TypeMinMax
Arguments PassedDatauint160511
BitMaskUint16065535
Return ValueDataUint160

Description

This function will return TRUE if any bits are set based on the passed BitMask for a uint32 datatype

TRANSIENT FUNCTIONS

None

Known Limitations With Design

  1. Per the FDD author, safety critical data is protected in an exclusive area but there is a possibility of corruption of non critical data.

  2. Refer to Design Rationale section on the top level of DiagcMgr Simulink model.

UNIT TEST CONSIDERATION

  1. Config files in the contract folder are for a test project with sample configurations using Application 6 and Application 10. Therefore with this configuration, the following files cannot be tested – DiagcMgrProxyAppl0, DiagcMgrProxyAppl1, DiagcMgrProxyAppl2, DiagcMgrProxyAppl3, DiagcMgrProxyAppl4, DiagcMgrProxyAppl5, DiagcMgrProxyAppl7, DiagcMgrProxyAppl8, DiagcMgrProxyAppl9.

Appendix

None

4 - DiagcMgrProxy_MDD

Module Design Document

For

Diagnostic Manager Proxy

VERSION: 2.0

DATE: 22-JUN-2016

Prepared By:

Spandana Balani

Location: The official version of this document is stored in the Nexteer Configuration Management System.

Revision History

Sl. No.DescriptionAuthorVersionDate
1ES101A_DiagcMgr_Design version 2 implementationSB1.011-Mar-2016
2ES101A_DiagcMgr_Design version 4 implementationSB2.022-Jun-2016

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 DiagcMgrPROXYAPPLX & High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation of DiagcmgrPRoxyApplX 8

4.2 Data Flow Diagram 8

4.2.1 Module level DFD 8

4.2.2 Sub-Module level DFD 8

4.3 COMPONENT FLOW DIAGRAM 8

5 Variable Data Dictionary 9

5.1 User defined typedef definition/declaration 9

5.2 Variable definition for enumerated types 9

6 Constant Data Dictionary 10

6.1 Program(fixed) Constants 10

6.1.1 Embedded Constants 10

6.1.1.1 Local 10

6.1.1.2 Global 10

6.1.2 Module specific Lookup Tables Constants 10

7 Software Module Implementation 11

7.1 Sub-Module Functions 11

7.1.1 Initialization Functions 11

7.1.1.1 INIT: DiagcMgrPROXYAPPLXInit1 11

7.1.1.2 Design Rationale 11

7.1.1.3 Store Module Inputs to Local copies 11

7.1.1.4 (Processing of function)……… 11

7.1.1.5 Store Local copy of outputs into Module Outputs 11

7.1.2 PERIODIC FUNCTIONS 11

7.1.2.1 Per: diagcmgrPROXYAPPLXPer1 11

7.1.2.2 Design Rationale 11

7.1.2.3 Store Module Inputs to Local copies 11

7.1.2.4 (Processing of function)……… 11

7.1.2.5 Store Local copy of outputs into Module Outputs 11

7.1.3 Interrupt Functions 11

7.1.4 Server Runnable Functions 12

7.1.4.1 GetDiagcDataApplX_Oper 12

7.1.4.2 GetNtcActvX_Oper 12

7.1.4.3 GetNtcDebCntrAppl0_Oper 12

7.1.4.4 GetNtcInfoApplX_Oper 12

7.1.4.5 GetNtcQlfrStsX_Oper 12

7.1.4.6 GetNtcStsX_Oper 13

7.1.4.7 SetNtcStsX_Oper 14

7.1.5 Local Function/Macro Definitions 14

7.1.5.1 Description 14

7.1.6 TRANSIENT FUNCTIONS 14

8 Known Limitations With Design 15

9 UNIT TEST CONSIDERATION 16

10 Appendix 17

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><MDD Guidelines>Process 04.02.01
<2><Software Naming Conventions>Process 04.02.01
<3><Coding standards>Process 04.02.01
<4>FDD – ES101A Diagnostic ManagerSee Synergy Subproject version
<Add if more available>

DiagcMgrPROXYAPPLX & High-Level Description

There are 11 proxy components whose design is same but the name of the components is based on the application number. ApplX is used through out the document in place of application number.

Design details of software module

Graphical representation of DiagcmgrPRoxyApplX

Graphical representation below is for the application 6 proxy component.

Data Flow Diagram

Module level DFD

N/A

Sub-Module level DFD

N/A

COMPONENT FLOW DIAGRAM

N/A

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)

Refer DiagcMgr_MDD

Variable definition for enumerated types

Enum NameElement NameValue
N/A

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

< All program specific constants will be defined in detail >

Local

Constant NameResolutionUnitsValue
See DataDict.m file
Refer DiagcMgr_MDD

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
Refer DiagcMgr_MDD

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

INIT: DiagcMgrPROXYAPPLXInit1

Design Rationale

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

PERIODIC FUNCTIONS

(Note: For multiple periodic functions, insert new headers at the “Header 2” level – subset of “7.1.2 Periodic Functions” and follow the same sub-section design shown below). If none required, place the text “None”)>

Per: diagcmgrPROXYAPPLXPer1

Design Rationale

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

Interrupt Functions

None

Server Runnable Functions

(Note: For multiple periodic functions, insert new headers at the “Header 2” level – subset of “7.1.2 Periodic Functions” and follow the same sub-section design shown below). If none required, place the text “None”)>

GetDiagcDataApplX_Oper

See DataDict.m file and model for detailed description.

GetNtcActvX_Oper

See DataDict.m file and model for detailed description.

X in the flowchart will change based on the proxy application number.

ErrorID ‘0’ is ensuring if NtcNr is within the valid range.

ErrorID ‘1’ is ensuring if ApplIdx is valid.

GetNtcDebCntrAppl0_Oper

See DataDict.m file and model for detailed description.

GetNtcInfoApplX_Oper

See DataDict.m file and model for detailed description.

GetNtcQlfrStsX_Oper

See DataDict.m file and model for detailed description.

X in the flowchart will change based on the proxy application number.

ErrorID ‘0’ is ensuring if NtcNr is within the valid range.

ErrorID ‘1’ is ensuring if ApplIdx is valid.

GetNtcStsX_Oper

See DataDict.m file and model for detailed description.

X in the flowchart will change based on the proxy application number.

ErrorID ‘0’ is ensuring if NtcNr is within the valid range.

ErrorID ‘1’ is ensuring if ApplIdx is valid.

SetNtcStsX_Oper

See DataDict.m file and model for detailed description.

X in the flowchart will change based on the proxy application number.

ErrorID ‘0’ is ensuring if NtcNr is within the valid range.

ErrorID ‘1’ is ensuring if ApplIdx is valid.

Local Function/Macro Definitions

Description

Proxies use functions from the private.c file, refer DiagcMgr MDD for function descriptions.

TRANSIENT FUNCTIONS

None

Known Limitations With Design

  1. Per the FDD author, safety critical data is protected in an exclusive area but there is a possibility of corruption of non critical data.

  2. Refer to Design Rationale section on the top level of DiagcMgrProxy Simulink model.

UNIT TEST CONSIDERATION

  1. Config files in the contract folder are for a test project with sample configurations using Application 6 and Application 10. Therefore with this configuration, the following files cannot be tested – DiagcMgrProxyAppl0, DiagcMgrProxyAppl1, DiagcMgrProxyAppl2, DiagcMgrProxyAppl3, DiagcMgrProxyAppl4, DiagcMgrProxyAppl5, DiagcMgrProxyAppl7, DiagcMgrProxyAppl8, DiagcMgrProxyAppl9.

Appendix

None