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

Return to the regular view of this page.

Component Implementation

1: DiagcMgr_IntegrationManual
2: DiagcMgr_MDD
3: DiagcMgr_PeerReviewChecklist
4: DiagcMgrProxy_MDD

Component Implementation

Component Documentation

1 - DiagcMgr_IntegrationManual

Integration Manual

For

Diagnostic Manager

VERSION: 7.0

DATE: 26-APR-2017

Prepared By:

Shruthi Raghavan,

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Spandana Balani	1.0	23-Apr-2015
2	Updated to FDD version 2	Spandana Balani	2.0	11-Mar-2016
3	Updated to FDD version 3	Spandana Balani	3.0	22-APR-2016
4	Updated to FDD version 4	Spandana Balani	4.0	22-Jun-2016
5	Added new parameter in configurator	Spandana Balani	5.0	30-Nov-2016
6	Remove Nvm block id for SnpshtDataAry	Spandana Balani	6.0	07-Dec-2016
7	Add Nvm block id for new LtchCntrAry NVM Added runnable scheduling for added runnables	Shruthi Raghavan	7.0	26-APR-2017

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

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	MDD Guidelines	See process v04.04.02 document from eRoom here
2	EA4 Software Naming Conventions	See process v04.04.02 document from eRoom here
3	Software Design And Coding standards	See process v04.04.02 document from eRoom here
4	FDD – ES101A Diagnostic Manager	See Synergy Design Subproject Version

Dependencies

SWCs

Module	Required Feature
None	N/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 calls "SetRamBlockSts" Non-RTE version (NvMProxy_SetRamBlockStatus).

RestoreNtcFltAryDft() , RestoreSnpshtAryDft(), RestoreDiagcMgrLtchCntrAryDft () – Non RTE Server Runnables (callback functions), 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.

Modules	Notes
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

Parameter	Notes	SWC
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr	Configuration of the DiagcMgr module	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR	Container with NTC number properties	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR/NTCOsApplicationRef	NTC Os Application. This defines the application corresponding to a particular NTC	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR/Debounce	Set to true if NTC is type debounce	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR/LtchgEna	Set to true if NTC is latched. Currently only a maximum of 20 Latching NTCs are supported in a project.	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR/LtchCntrThd	Set a value between 1-255 if NTC is latching. Else, the value is ignored & written as 0XFF in the generated file by default when needed.	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR/MfgNtcInhibInNonOper	Boolean Value of <Mfg NTC Inhibit Non-Operate States> column for corresponding NTC in the NTC Master List of the project.	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR/MfgNtcInhibInOper	Boolean Value of <Mfg NTC Inhibit Operate State> column for corresponding NTC in the NTC Master List of the project.	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/NTCNR/NtcPwrCycLtch	Boolean Value of <NTC Power Cycle Latch> column for corresponding NTC in the NTC Master List of the project.	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DTCEnaCndn	Container with DTC ENABLE Criteria	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DTCEnaCndn/DTC	This defines the DEM DTC Class.	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DTCEnaCndn/Bit_X¹	Set to true if Enable Condition for Bit X¹ is applicable to configured DTC	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DTCEnaCndn/DiagcMgrDTCIdx	Value represents index value DiagcMgr uses internally for NTC mapping to DTCs to the Event ID that the Dem identifies for a particular DTC	DiagcMgr
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DiagcMgrGeneral	Container with General DiagcMgr configuration	DiagcMgr
/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
/Nexteer/EcucDefs_DiagcMgr/DiagcMgr/DiagcMgrGeneral/DEMTOTNROFDTC	This needs to be configured to an expression that would result in the total number DTCs that are configured in the system based on generated Dem code	DiagcMgr

¹ Note: X = _0 to 15

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
N/A

Manual Configuration Changes

Constant	Notes	SWC
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.

Init	Scheduling Requirements	Trigger
DiagcMgProxyApplXInit1	Init 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
DiagcMgrInit1	To be scheduled after CM102A init & after DiagcMgrProxyApplXInit1¹	RTE Init

Runnable	Scheduling Requirements	Trigger
DiagcMgrPer1	None	RTE 2ms Task
DiagcMgrPer2	None	RTE 100ms Task
ClrAllDiagc_Oper	Server Runnable	Client Call
ClrLtchCntrData_Oper	Server Runnable	Client Call
ClrSnpshtData_Oper	Server Runnable	Client Call
CnvSnpshtData_<Type>^3,5	Server Runnable	Client Call
DiagcMgrIninCore_Oper	Server Runnable	Internal to DiagcMgr²
GetNtcActvCore_Oper	Server Runnable	Internal to DiagcMgr²
GetNtcQlfrStsCore_Oper	Server Runnable	Internal to DiagcMgr²
GetNtcStsCore_Oper	Server Runnable	Internal to DiagcMgr²
ReadNtcFltAryCore_Oper³	Server Runnable	Client Call
ReadNtcInfoAndDebCntr_Oper³	Server Runnable	Client Call
ReadSnpshtData_Oper	Server Runnable	Client Call
SetNtcStsCore_Oper	Server Runnable	Internal to DiagcMgr²
DiagcMgrPwrDwn	Non RTE Server Runnable	Client Call
RestoreNtcFltAryDft	Non RTE Server Runnable	Client Call
RestoreDiagcMgrLtchCntrAryDft	Non RTE Server Runnable	Client Call
ReadLtchCntrData	Server Runnable	Client Call
RestoreSnpshtAryDft	Non RTE Server Runnable	Client Call
DiagcMgrProxyApplXInit1¹	Schedule before DiagcMgrInit1	RTE Init
DiagcMgrProxyApplXPer1¹	None	RTE 10ms Task
GetDiagcDataApplX_Oper¹	Server Runnable	Internal to DiagcMgr²
GetNtcActvX_Oper^1,3	Server Runnable	Client Call
GetNtcDebCntrAppl0_Oper¹	Server Runnable	Client Call
GetNtcInfoApplX_Oper¹	Server Runnable	Internal to DiagcMgr²
GetNtcQlfrStsX_Oper^1,3	Server Runnable	Client Call
GetNtcStsX_Oper^1,3	Server Runnable	Client Call
SetNtcStsX_Oper^1,3	Server Runnable	Client Call
SetNtcStsAndSnpshtDataX_Oper^1,3	Server Runnable	Client Call
UpdDtcEnaCdn⁴	Non RTE Server Runnable	Client Call

¹X in the Runnable name represent the application number. There 11 applications (0 to 10) and each application has a ProxyDiagcMgr component. One set of these server runnables exist in each proxy component.

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

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

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

⁵The <Type> in this function can be f32,logl,s08,s16,s32,u08 or u16

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
GlobalShared_START_SEC_VAR_NOINIT_UNSPECIFIED	SnpshtDataAry_M

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

Usage

Feature	RAM	ROM
<Memmap usuage info>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

*See DataDict.m

1. 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” and “NvMConf_NvMBlockDescriptor_Rte_NvmBlock_DiagcMgr_DiagcMgrLtchCntrAry” 2. The shadow RAM for SnpshtDataAry NVM lives in the global variable SnpshtDataAry_M. This should be mapped appropriately.

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

There is the following compiler warning shows up in the compilation of DiagcMgr.c.

Justification: The intention of CnvSnpshtData_f32_Oper server runnable is to retain the bits of the single precision float input argument as is in the uint32 output. Typecasting the float32 input to uint32 will not preserve the bits as intended hence this type of casting is required.

Note: We are deviating from MISRA Rule 11.4 (refer static analysis guideline D 11.4.5)

The components that need to be integrated/ brought into the developer project are:
1. DiagcMgr
2. DiagcMgrStub
3. DiagcMgrProxyApplX for each application(#X) that exists in the project.

Note: In DiagcMgr davinci component interface, only the client ports of applications that are present in the project will have server ports to connect to. All the client ports that do not have the corresponding application in the project need to be connected to the corresponding server port in DiagcMgr_Stub component.

2 - DiagcMgr_MDD

Module Design Document

For

Diagnostic Manager

VERSION: 11.0

DATE: 14-DEC-2017

Prepared By:

Shruthi Raghavan

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

Revision History

Description	Author	Version	Date
Initial Version	SB	1.0	23-Apr-2015
Added to Design Limitations section	KMC	2.0	03-Jun-2015
ES101A_DiagcMgr_Design version 2 implementation	SB	3.0	11-Mar-2016
ES101A_DiagcMgr_Design version 3 implementation	SB	4.0	19-Apr-2016
ES101A_DiagcMgr_Design version 4 implementation	SB	5.0	22-Jun-2016
Added DETs to “SetNtcStsCore_Oper” server runnables	SB	6.0	26-Sep-2016
Updated to fix anomalies EA4#8118 and EA4#8115	SB	7.0	02-Dec-2016
Updated the graphical representation. Added server runnables CnvSnpshtData_*, noted design limitations and design rationales and added local functions	SR	8.0	21-Apr-2017
Updated Unit Test considerations as per EA4#9649	SR	9.0	29-Jun-2017
Updated Unit Test considerations for new process to handle configuration parameters for PIL testing. Also updated design limitations per latest design baseline.	SR	10.0	26-Sep-2017
Removed Static analysis explanation from DiagcMgr PwrDwn function’s rationale because it is no longer applicable. Also removed design limitation that was corrected in the current design version (5.3.0)	SR	11.0	14-Dec-2017

Table of Contents

1 Abbrevations And Acronyms 6

2 References 7

3 DiagcMgr & High-Level Description 8

4 Design details of software module 9

Graphical representation of Diagcmgr 9

4.1 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 9

5 Variable Data Dictionary 10

5.1 User defined typedef definition/declaration 10

5.2 Variable definition for enumerated types 10

5.3 Global Variable definition 10

6 Constant Data Dictionary 11

6.1 Program(fixed) Constants 11

6.1.1 Embedded Constants 11

6.1.1.1 Local 11

6.1.1.2 Global 11

Module specific Lookup Tables Constants 11

6.1.2 11

7 Software Module Implementation 12

7.1 Sub-Module Functions 12

7.1.1 Initialization Functions 12

7.1.2 PERIODIC FUNCTIONS 12

7.1.2.1 Per: diagcmgrPer1 12

7.1.2.1.1 Design Rationale 12

7.1.2.2 Per: diagcmgrPer2 12

7.1.2.2.1 Design Rationale 12

7.1.3 Interrupt Functions 12

Server Runnable Functions 13

7.1.4 13

7.1.4.1 ClrAllDiagc_Oper 13

7.1.4.2 ClrSnpshtData_Oper 13

7.1.4.2.1 Design Rationale 13

7.1.4.3 DiagcMgrIninCore_Oper 13

7.1.4.4 DiagcMgrPwrDwN 14

7.1.4.4.1 Design Rationale 14

7.1.4.5 UpdDtcEnaCdn 14

7.1.4.5.1 Design Rationale 15

7.1.4.6 GetNtcActvCORE_Oper 15

7.1.4.7 GetNtcQlfrStsCORE_Oper 15

7.1.4.8 GetNtcStsCORE_Oper 15

7.1.4.9 ReadNtcFltAry_Oper 15

7.1.4.9.1 Design Rationale 15

7.1.4.10 ReadNtcInfoAndDebCntr_Oper 15

7.1.4.10.1 Design Rationale 15

7.1.4.11 ReadSnpshtData_Oper 15

7.1.4.12 CnvSnpshtData_f32_Oper 15

7.1.4.13 CnvSnpshtData_logl_Oper 15

7.1.4.14 CnvSnpshtData_s08_Oper 15

7.1.4.15 CnvSnpshtData_s16_Oper 15

7.1.4.16 CnvSnpshtData_s32_Oper 15

7.1.4.17 CnvSnpshtData_u08_Oper 16

7.1.4.18 CnvSnpshtData_u16_Oper 16

7.1.4.19 SetNtcStsCore_Oper 16

7.1.4.19.1 Design Rationale 16

7.1.4.20 ClrLtchCntrData_Oper 16

7.1.4.21 ReadLtchCntrData_Oper 16

7.1.4.22 RestoreDiagcMgrLtchCntrAryDft 17

7.1.4.23 RestoreNtcFltAryDft 17

7.1.4.24 RestoreSnpshtAryDft 17

7.1.5 Local Function/Macro Definitions 17

7.1.5.1 Local Function #1 17

7.1.5.1.1 Description 17

7.1.5.2 Local Function #2 17

7.1.5.3 Description 17

7.1.5.3.1 Design Rationale 18

7.1.5.4 Local Function #3 18

7.1.5.4.1 Design Rationale 18

7.1.5.5 Local Function #4 18

7.1.5.5.1 Design Rationale 18

7.1.5.6 Local Function #5 18

7.1.5.6.1 Design Rationale 18

7.1.5.7 Local Function #6 18

7.1.5.7.1 Design Rationale 19

7.1.5.8 Local Function #7 19

7.1.5.8.1 Design Rationale 19

7.1.5.9 Local Function #8 19

7.1.5.9.1 Design Rationale 19

7.1.6 GLObAL Function/Macro Definitions 19

7.1.6.1 GLObAL Function #1 19

7.1.6.1.1 Description 20

GLObAL Function #2 20

7.1.6.2 20

7.1.6.2.1 Description 20

GLObAL Function #3 20

7.1.6.3 20

7.1.6.3.1 Description 20

GLObAL Function #4 20

7.1.6.4 20

7.1.6.4.1 Description 20

GLObAL Function #5 20

7.1.6.5 20

7.1.6.5.1 Description 20

7.1.6.6 GLObAL Function #6 20

7.1.6.6.1 Description 20

7.1.7 TRANSIENT FUNCTIONS 21

8 Known Limitations With Design 22

9 UNIT TEST CONSIDERATION 23

10 Appendix 24

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module 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

#	Title	Version
1	MDD Guideline EA4	1.02
2	EA4 Software Naming Conventions	1.02
3	Software Design and Coding standards	2.01
4	ES101A_DiagcMgr_Design	See Synergy Subproject version

DiagcMgr & High-Level Description

This function is responsible for handling all the NTCs that are used by different FDDs. The Diagnostic Manager sets the Ntc called by any component and requests the system to either ramp down to Disable or take no action. It also handles latched Ntcs & owns the associated NTCNR_0x0A Ntc.

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 Name	Element Name	User Defined Type	Legal Range (min)	Legal Range (max)
NtcMapRec1	ApplIdx	Uint8	0	10
	NtcInfoIdx	uint8	0	255
	DebCntrIdx	Uint8	0	255
NtcInfoRec4	NtcStInfo	Uint8	0	255
	Sts	Uint8	0	255
	AgiCntr	Uint8	0	255
Ary1D_NtcInfoRec4		NtcInfoRec4[]¹
Ary1D_NtcInfoRec4_DiagcMgrProxyApplX³		NtcInfoRec4[]¹
Ary1D_s16_DiagcMgrProxyApplX³		Sint16[]²

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 Name	Element Name	Value
See DataDict.m file

Global Variable definition

Name	Type
SnpshtDataAry_M[8]¹	SnpshtDataRec2

Name	Element Name	Type	Min	Max
SnpshtDataRec2	SpclSnpshtData0	uint32	0	4294967295
	SpclSnpshtData1	uint32	0	4294967295
	SpclSnpshtData2	uint32	0	4294967295
	MicroDiagcData	uint32	0	4294967295
	IgnCntr	uint32	0	4294967295
	HwTq	sint16	-10	10
	MotTqCmdMrfScad	sint16	-8.8	8.8
	BrdgVltg	uint16	6	26.5
	EcuTFild	sint16	-50	150
	NtcNr	NtcNr1	NTCNR_0X001	NTCNR_0X1FF
	NtcStInfo	uint8	0	255
	SysSt	SysSt1	SYSST_DI	SYSST_WRMININ

Notes:

1- This variable is mapped to MemMap – “GlobalShared_START_SEC_VAR_NOINIT_UNSPECIFIED”

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value
See DataDict.m file	N/A	N/A	N/A
IMDTSHTDWNFLT_CNT_U16	1	Counts	5U
CTRLDSHTDWNFLT_CNT_U16	1	Counts	6U
INFOONLYFLT_CNT_U16	1	Counts	7U
TOTNROFDTC_CNT_U08⁴	1	Counts	Configured
PimSnpshtDataAry_rec	N/A	N/A	SnpshtDataAry_M
D_MAXNUMBEROFNTCS_CNT_U16	1	CNT	512U

4 - Number of DTCs for that program.

Global

Constant Name	Value
See DataDict.m file	N/A

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
DIAGCMGRNTCMAP_CNT_REC [512]	NtcMapRec1	Configured	DiagcMgr_START_SEC_CODE
NTCNRARYAPPLX_CNT_U16 [Configured]⁵	1	Configured	DiagcMgr_START_SEC_CODE
DTCENAMASK [Configured]⁶	1	Configured	DiagcMgr_START_SEC_CODE
DEMDTCEVEIDMAP [Configured]⁶	1	Configured	DiagcMgr_START_SEC_CODE
FLTRESPRAMPTBL_ULS_F32 [5]	Single Precision Float	{0.1F,0.125F,0.2F,1.0F,10.0F}	DiagcMgr_START_SEC_CODE
DIAGCMGRNTCPPTYARY_CNT_U08[512]	1	Configured	DiagcMgr_START_SEC_CODE
DIAGCMGRLISTOFLTCHGNTC_CNT_ENUM[20⁷]	1	Configured	DiagcMgr_START_SEC_CODE
DIAGCMGRNTCLTCHCNTRTHD_CNT_U08[20⁷]	1	Configured	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.

7 – The length of this array depends on MaximumNumberOfLatching Ntcs the software is designed to handle – currently it is 20.

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

None

PERIODIC FUNCTIONS

Per: diagcmgrPer1

This function exists in “DiagcMgr.c” file. Refer Simulink model for details

Design Rationale

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

Per: diagcmgrPer2

This function exists in “DiagcMgr.c” file. Refer Simulink model for details

Design Rationale

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

Interrupt Functions

None

Server Runnable Functions

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.

Design Rationale

“NvMConf_NvMBlockDescriptor_Rte_NvmBlock_DiagcMgr_SnpshtDataAry” 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.

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.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.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.h
QAC flags MISRA Rule 9.1 for HistNtcFltAry_T_rec being used to write to PIM before initialization but it isn’t actually an issue because the logic only uses the elements of the array that have been written to.

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

ReadSnpshtData_Oper

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

CnvSnpshtData_f32_Oper

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

CnvSnpshtData_logl_Oper

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

CnvSnpshtData_s08_Oper

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

CnvSnpshtData_s16_Oper

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

CnvSnpshtData_s32_Oper

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

CnvSnpshtData_u08_Oper

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

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

Design Rationale

The array DTCENAMASK is indexed by DtctempIdx_Cnt_T_u08 which corresponds to the lower 8-bits of the FltRespTbl. So the index can range from [0,255].

However the calibration PrmDiagcMgrFltResp_u16 is checked (using DET) at init functions of each ApplProxy such that the value of the lower 8-bits of each of its elements are in the range of [0,sizeof(DTCENAMASK)]. So there will never be an out-of-bounds array access scenario on the DTCENAMASK array.

Note: Lower 8-bits corresponds to FLTRESPDTCIDX_CNT_U16 mask being 0xFF.

ClrLtchCntrData_Oper

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

ReadLtchCntrData_Oper

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

RestoreDiagcMgrLtchCntrAryDft

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

Local Function #1

Function Name	ProcRampResp	Type	Min	Max
Arguments Passed	NtcNr_Cnt_T_u16	uint16	0	511
	DiagcData_T_rec	DiagcDataRec2
	DiagcData_T_rec .DiagcSts		0	255
	DiagcData_T_rec .ActvRampRate		0.1	500
	DiagcData_T_rec ActvMotTqCmdSca		0	1
	ProxySetNtcData_T_rec	DiagcDataRec2
	ProxySetNtcData_T_rec .DiagcSts		0	255
	ProxySetNtcData_T_rec .ActvRampRate		0.1	500
	ProxySetNtcData_T_rec ActvMotTqCmdSca		0	1
Return Value	N/A

Description

Refer ‘ProcessRampResponse and DiagcSts’ block in Simulink model for DiagcMgr

This function exists in “DiagcMgr.c” file.

Local Function #2

Function Name	UpdSnpshtData	Type	Min	Max
Arguments Passed	SpclSnpshtData0_Cnt_T_u32	uint32	0	4294967295
	SpclSnpshtData1_Cnt_T_u32	uint32	0	4294967295
	SpclSnpshtData2_Cnt_T_u32	uint32	0	4294967295
	McuDiagcSpplData_Cnt_T_u32	uint32	0	4294967295
	IgnCntr_Cnt_T_u32	uint32	0	4294967295
	HwTq_Cnt_T_s5p10	sint16	-10	10
	MotTqCmdMrfScad_Cnt_T_s5p10	sint16	-8.8	8.8
	BrdgVltg_Cnt_T_u6p10	uint16	6	26.5
	EcuTFild_Cnt_T_s8p7	sint16	-50	150
	NtcNr_Cnt_T_u16	NtcNr1	NTCNR_0X001	NTCNR_0X1FF
	NtcStInfo_Cnt_T_u08	uint8	0	255
	SysSt_Cnt_T_enum	SysSt1	SYSST_DI	SYSST_WRMININ
Return Value	N/A

Description

Refer ‘UpdSnpshtData’ block in Simulink model for DiagcMgr. This function exists in “DiagcMgr.c” file

Design Rationale

Local Function #3

Function Name	GetNtcInfoApplX	Type	Min	Max
Arguments Passed	ApplIdx_Cnt_T_u08	uint8	0	255
	NtcInfoIdx_Cnt_T_u08	uint8	0	255
	*NtcInfoPtr_Cnt_T_rec	NtcInfoRec4	See DT def	See DT def
Return Value	ApplIDValid_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

The function is a switch case that calls the GetNtcInfo of correct application to modify the value of NtcInfo at the address passed as an argument. It should be used in Non-RTE context only.

Local Function #4

Function Name	GetNtcInfoApplXRte	Type	Min	Max
Arguments Passed	ApplIdx_Cnt_T_u08	uint8	0	255
	NtcInfoIdx_Cnt_T_u08	uint8	0	255
	*NtcInfoPtr_Cnt_T_rec	NtcInfoRec4	See DT def	See DT def
Return Value	ApplIDValid_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

The function is a switch case that calls the GetNtcInfo of correct application to modify the value of NtcInfo at the address passed as an argument. It should be used in RTE context only.

Local Function #5

Function Name	UpdDtcSts	Type	Min	Max
Arguments Passed	NtcMapIdx_Cnt_T_u16	Uint16	0	511
	NtcInfoRecSts_Cnt_T_u08	uint8	0	255
	DtctempIdx_Cnt_T_u08	Uint8	0	TOTNROFDTC_CNT_U08^?
	* DtcIdxCurrSts_Cnt_T_u08	Uint	0	255
Return Value	None	N/A	N/A	N/A

^? – This is a configurable constant.

Design Rationale

Implement "Update DTC Status" subblock from Per2 in the FDD. Note that it is called inside a while loop. Created for complexity metrics compliance with design and coding standards.

Local Function #6

Function Name	ProcNtcStsPassd	Type	Min	Max
Arguments Passed	NtcNr_Cnt_T_enum	NtcNr1	1	511
	*NtcInfo_Cnt_T_rec	NtcInfoRec4	See DT def	See DT def
	*NtcInfoDebCntr_Cnt_T_s16	Sint16	-32768	32767
Return Value	None	N/A	N/A	N/A

Design Rationale

Implements 'NTCSTS_PASSD' inside SetNtcStsCore block of the DiagcMgr simulink model in the FDD. Created to reduce the cyclomatic complexity of SetNtcStsCore_Oper() server runnable.

Local Function #7

Function Name	ProcNtcStsPrePassd	Type	Min	Max
Arguments Passed	NtcNr_Cnt_T_enum	NtcNr1	1	511
	DebStep_Cnt_T_u16	Uint16	0	65535
	*NtcInfo_Cnt_T_rec	NtcInfoRec4	See DT def	See DT def
	*NtcInfoDebCntr_Cnt_T_s16	Sint16	-32768	32767
Return Value	None	N/A	N/A	N/A

Design Rationale

Implements 'NTCSTS_PREPASSD' inside SetNtcStsCore block of the DiagcMgr simulink model in the FDD. Created to reduce the cyclomatic complexity of SetNtcStsCore_Oper() server runnable.

Local Function #8

Function Name	ChkAgiCntr	Type	Min	Max
Arguments Passed	AgiCntr_Cnt_T_u08	uint8	0	255
	Sts_Cnt_T_u08	uint8	0	255
	NtcMapIdx_Cnt_T_u16	uint16	0	511
	*NtcFltAryIdx_Cnt_T_u16	uint16	0	20
	*HistFltAryIdx_Cnt_T_u16	uint16	0	20
	HistNtcFltAry_T_rec	NtcFltInfoRec2	-	-
	HistNtcFltAry_T_rec.NtcNr	NtcNrWithResd1	0	511
	HistNtcFltAry_T_rec.AgiCntr	uint8	0	255
	HistNtcFltAry_T_rec.Sts	uint8	0	255
Return Value	None	N/A	N/A	N/A

Design Rationale

Implements the 'Check Aging Counter' in DiagcMgrPwr block of DiagcMgr simulink model in FDD. Created to reduce the static path count of DiagMgrPwrDwn() server runnable.

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 Name	ProcProxyRampRespAndDiagcSts	Type	Min	Max
Arguments Passed	NtcNr_Cnt_T_u16	uint16	0	511
	ProxyDiagcData_T_rec	DiagcDataRec2
	ProxyDiagcData_T_rec .DiagcSts		0	255
	ProxyDiagcData_T_rec .ActvRampRate		0.1	500
	ProxyDiagcData_T_rec ActvMotTqCmdSca		0	1
Return Value	N/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 #2

Function Name	DiagcMgrSetBits_u16	Type	Min	Max
Arguments Passed	Data	uint16	0	511
	BitMask	Uint16	0	511
Return Value	Data	Uint16	0	511

Description

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

GLObAL Function #3

Function Name	DiagcMgrSetBits_u08	Type	Min	Max
Arguments Passed	Data	Uint8	0	255
	BitMask	Uint8	0	255
Return Value	Data	Uint8	0	255

Description

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

GLObAL Function #4

Function Name	DiagcMgrClrBits_u08	Type	Min	Max
Arguments Passed	Data	Uint8	0	255
	BitMask	Uint8	0	255
Return Value	Data	Uint8	0	255

Description

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

GLObAL Function #5

Function Name	DiagcMgrReadBit_u08	Type	Min	Max
Arguments Passed	Data	Uint8	0	255
	BitMask	Uint8	0	255
Return Value	Data	Uint8	0	255

Description

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

GLObAL Function #6

Function Name	DiagcMgrReadBit_u16	Type	Min	Max
Arguments Passed	Data	uint16	0	511
	BitMask	Uint16	0	511
Return Value	Data	Uint16	0	511

Description

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

TRANSIENT FUNCTIONS

None

Known Limitations With Design

Per the FDD author, safety critical data is protected in an exclusive area but there is a possibility of corruption of non critical data.
Refer to Design Rationale section on the top level of DiagcMgr Simulink model.
GetErrorStatus() for NVM block isnt used in the FDD because
1. Default block is used that resets appln crc to zero, so the latch counter array will get reset as it will enter the condition swapplcrc!=nvmapplcrc
2. Above point assumed that a valid swapplncrc will never be zero
3. It is known and noted that if there is an nvm read problem while ntcs are set we clear the ntcs as well
This design does not support having multiple Flash application CRC regions being allowed to set latching ntcs [Note: As of today, no programs have more than 1 Flash application crc region]
DiagcMgr_Cfg.c and DiagcMgr_Cfg.h files define the NTC arrays as uint16 (base type of NtcNrwithResd1) arrays instead of the NtcNrResd1 type arrays because they do not have visibility to Rte types. [Not actually a design limitation : noted here for future reference]
In v3.0.0 of the implementation it was found that the DiagcMgr_Cfg_Private.h file was being included in the integration project’s Rte_UserTypes.h file because of the need for visibility to the Ary Types that are defined as typedefs in there. At that point it was decided that it was better to rename it as DiagcMgr_Cfg.h file instead. [Not actually a design limitation : noted here for future reference]

UNIT TEST CONSIDERATION

For SetNtcStsCore_Oper: The input value of the lower 8 bits of each element of PrmDiagcMgrFltResp_u16 calibration while unit testing this runnable should be such that its maximum is [sizeof(DTCENAMASK)-1] and minimum is 0.

Appendix

None

3 - DiagcMgr_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
DiagcMgrNonRte
MDD
PolySpace
Version History

Sheet 1: Summary Sheet

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Summary Sheet

Component Short Name:

Windows User: Intended Use: Identify which component is being reviewed. This should match the component short name from the DataDict.m fileand the middle part of the Synergy project name, e.g. Assi for the SF001A_Assi_Impl Synergy project

DiagcMgr

Revision / Baseline:

Windows User: Intended Use: Identify the implementation baseline name intended to be used for the changed component when changes are approved E.g. SF001A_Assi_Impl_1.2.0

ES101A_DiagcMgr_Impl_5.3.0

Change Owner:

Windows User: Intended Use: Identify the developer who made the change(s) being reviewed

Shruthi Raghavan

Work CR ID:

Windows User: Intended Use: Identify the Implementation Work CR whose work is being reviewed (may be more than one)

EA4#18204

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:

Check the file types that needed modification for the Work CR(s); macros for the check boxes will populate the appropriate checklist tabs for the review.

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:

At start of review, all items below should be marked "No". At the end of the review, all items should be marked "Yes" or "N/A" where N/A indicates the reviewers have reviewed the existing (unchanged) item and confirmed no updates were needed for the Work CR(s).

Yes

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

Anomaly Fixes for EA4#16551

Converted manually to new folder structure : DO NOT REGENERATE POLYSPACE OR INTEGRATION FILES

OR GENERATION SCRIPT USING SWCSUPRT.BAT

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 SWC Owner and/or SWC Design author and Integrator and/or SW Lead 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.

Each peer review shall start with a clean copy of the latest peer review checklist template. Before the peer review, the change owner shall:
o Review the previous component peer review and copy any relevant comments to the new review sheet.
o Review all checklist items and make all corrections needed, so that the component is ready for peer review. The expectation is that peer review should find very few issues,
because the change owner has already used the checklist to ensure the component changes are complete and correct.
o Fill in all file name and version information as needed on peer review checklist tabs (file names may be copied from the previous peer review where appropriate)
o Fill in checklist answers (Yes/No/NA pulldowns) ONLY on those items which are NA for the current change. All other checklist items should be blank going into the review
meeting.

During the peer review meeting:
o For each page of the review, first review the items already marked as N/A for this change, to confirm that reviewers agree with this assessment; change the checklist box to
blank if it is found that the item does apply.
o Then review the items with the checklist box blank. After reviewing each of these items, the checklist box will be marked as "Yes", or the checklist box will be marked as
"No" with needed rework indicated or with rationale indicated.
o If any items are marked "No" with rationale indicated, this must be approved by a software supervisor or the software manager; there is a line in the "Review Board" section
of each tab to indicate who approved the "No" items on that tab.

Sheet 2: Synergy Project

Rev 2.00

29-Nov-17

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

N/A

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

.gpj file in tools folder matches .gpj generated by TL109 script

Comments:

See comment 1

File/folder structure is correct per documentation in

Yes

Comments:

TL109A_SwcSuprt

General Notes / Comments:

1. TL109A does not create individual gpjs for the diagcmgr and proxy files. So these project files are manually created and must be updated as needed.

Review Board:

Change Owner:

Shruthi Raghavan

Review Date :

12/14/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Kathleen Creager

Lucas Wendling

Samanth Kumaraswamy

Gustavo Nunes

Rationale/justification for items marked "No" approved by:

Lucas Wendling

Sheet 3: DiagcMgrNonRte

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Source Code Review)

Source File Name:

DiagcMgrNonRTE.c

Source File Revision:

Windows User: Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) 8

Header File Name:

DiagcMgr.h

Header File Revision:

Windows User: Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) 9

MDD Name:

DiagcMgr_MDD.doc

Revision:

Windows User: Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) 11

SWC Design Name:

ES101A_DiagcMgr_Design

Revision:

Windows User: Intended Use: For FDDs, list the Synergy baseline number (just the number part of the Synergy baseline name) of the FDD baseline being implemented. E.g., for SF001A_Assi_Design_1.3.1, this field would say "1.3.1" 5.3.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 1.01

EA4 Software Naming Convention followed:

Version: 1.02

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

Verified no possibility of uninitialized variables being

N/A

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

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:

(including any anomaly number(s) being fixed) and

Work CR number

Code accurately implements SWC Design (Document or Model)

Yes

Comments:

in all areas where code was changed and/or Simulink

model was color-coded as changed and/or mentioned

in SWC Design change log. (This item includes looking at all

layers of Simulink model for possible color coding not

reflected at a higher level, and includes looking at any

intermediate SWC Design versions between the version being

implemented and the version that was included as a

subproject in the previous implementation.)

Code comparison against previous version matches

Yes

Comments:

changes needed as described by the work CR(s), all

parent CRs and parent anomalies, and the SWC

Design change log.

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.

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

Yes

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Windows User: Intended Use: list version/revision of latest released Software Design and Coding Standards document. Version: 2.01

Code comments are clear, correct, and adequate

N/A

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

N/A

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

Yes

Comments:

is per standard

All access of motor control loop data uses macros

N/A

Comments:

generated by the motor control manager

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-unsigned 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 SWC Design DataDict.m file : [N53]

All code is mapped with SWC Design (all SWC

Yes

Comments:

Design subfunctions and/or model blocks identified

put in comment for update nvm : done 12/14/2017

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

Yes

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

Yes

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

EA4#18554 (See comment 1)

General Notes / Comments:

1. A continuous improvement ICR (EA4#18554) was created for optimizing the number of times the FltAry NvM is written to

Review Board:

Change Owner:

Shruthi Raghavan

Review Date :

12/14/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

Samanth Kumaraswamy

Integrator and or
SW lead:

Comments:

Gustavo Nunes

Unit test co-ordinator:

N/A

Comments:

Not a required reviewer for

this change

Other Reviewer(s):

Lucas Wendling

Kathleen Creager

Rationale/justification for items marked "No" approved by:

Sheet 4: MDD

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

DiagcMgr_MDD.docx

MDD Revision:

Source File Name:

DiagcMgr.c

Source File Revision:

Source File Name:

DiagcMgr_private.c

Source File Revision:

Source File Name:

DiagMgrNonRte.c

Source File Revision:

Source File Name:

DiagcMgrProxyApplX.c (X=0,1,2,4,5,7,8,9)

Source File Revision:

Source File Name:

DiagcMgrProxyAppl3.c

Source File Revision:

Source File Name:

DiagcMgrProxyAppl6.c

Source File Revision:

Source File Name:

DiagcMgrProxyAppl10.c

Source File Revision:

Source File Name:

DiagcMgrStub.c

Source File Revision:

Source File Name:

DiagcMgr_Cfg.c.tt

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

N/A

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

removed a fixed limitation

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 SWC

N/A

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

removed consideration that was put in for design issue

General Notes / Comments:

DIAGCMGR_DEMCHK must be tested with ON and OFF? Leave them turned on & justify coverage issues 9/14/2017

Review Board:

Change Owner:

Shruthi Raghavan

Review Date :

12/14/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Rationale/justification for items marked "No" approved by:

Sheet 5: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

DiagcMgr.c

Source File Revision:

Source File Name:

DiagcMgr_private.c

Source File Revision:

Source File Name:

DiagMgrNonRte.c

Source File Revision:

Source File Name:

DiagcMgrProxyApplX.c (X=0,1,2,4,5,7,8,9)

Source File Revision:

Source File Name:

DiagcMgrProxyAppl3.c

Source File Revision:

Source File Name:

DiagcMgrProxyAppl6.c

Source File Revision:

Source File Name:

DiagcMgrProxyAppl10.c

Source File Revision:

Source File Name:

DiagcMgrStub.c

Source File Revision:

Source File Name:

DiagcMgr_Cfg.c.tt

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b

2013b

TL109A sub project version:

2.2.0

Quality Check Items:

Rationale is required for all answers of No

tools/local folders' header files are appropriate and

N/A

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

reviewed changes

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

For any component source files (.c, .h, generated Cfg.c and Cfg.h)

N/A

Comments:

with conditional compilation, has Polyspace been run with all

combinations of build constants that can be used together in a build?

(Note which conditional compilation results have been archived)

Cyclomatic complexity and Static path count OK

Comments:

for all functions in the component per Design

Cyclomatic complexity = 23. See reasoning below.

and Coding Standards rule [N47]

General Notes / Comments:

13.7 warning in Polyspace exists in DiagcMgr.c file because of the config constants - TOTNROFDTC_CNT_U08, DEMTOTNROFDTC_CNT_U08 - and trying to compare two constants but this values change based on DTC configuration

Polyspace complains about unreachable code because of above config constants - Analysed and is OK.

Cyclomatic Complecity maximum is 23 for the server runnable ReadNtcInfoAndDebCntr_Oper in DiagcMgr.c. There is no logical or efficient way to breakdown the conditions into meaningful subfunctions.

Orange check for indexing DTCENAMASK array : A wrong calibration of DiagcMgrFltResp table is the only reason that an out of bounds array access can happen but that will be caught by DET checks. See MDD for additional rationale. 10/25/2017

NtcInfoDebCntrArg update in the Prefaild case in SetNtcStsCore cannot overflow because of the preconditions to enter DebCntr<MAXDEBCNTRVAL case : So the overflow orange check reported is verified to be a non issue.

if((NtcNr_Arg < NTCNR_0X001) || (NtcNr_Arg > NTCNR_0X1FF)) condition is used in code to ensure ntc numbers to be in range and to set a dtc otherwise. This check is done in 5 server runnables in each proxy component. However, the DRS for NtcNumber being in the 1-511 range makes else case appear as unreachable code to Polyspace. This is okay, because the DET check is there for "abnormal" conditions where the NTC number at the input of these runnables might be outside the allowed range. 10/25/2017.
Similar checks are also done in SetNtcStsCore_Oper() which causes 2 deadcode warnings that can be justified by the same reason given above. 10/25/2017

UpdSnpshtData unreachable code seems to be due to unknown range of the SnpshtDataAry_M global variable used as NVM Shadow Ram.

When NtcInfo_Cnt_T_rec is returned from a function via a pointer, Polyspace is unable to recognize that it was initialized inside with valid values. In case no valid value is returned from the local function, code uses a flag from the function to initialize the used members of the structure to default values. so checks for Non-initialized local variable is ok. 10/25/2017

Review Board:

Change Owner:

Shruthi Raghavan

Review Date :

12/14/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Other Reviewer(s):

Lucas Wendling

Kathleen Creager

Samanth Kumaraswamy

Gustavo Nunes

Rationale/justification for items marked "No" approved by:

Lucas Wendling

Sheet 6: Version History



File Version History
Version	Description	Author(s)	Revision Date	Approved By	Approved Date	Status
						Draft/ Released










Template Version History
Version	Description	Author(s)	Revision Date	Approved By	Approved Date	Status
1.0	Initial Version	SW Engineering team	24-May-15	NA	NA	Released
1.01	Changed name to be EA4 specific	SW Engineering team	25-Jun-15	NA	NA	Released
1.02	Modified Summary Sheet General Guidelines, Clarified wording on first item in Synergy project sheet.	SW Engineering team	30-Jul-15	NA	NA	Released
1.02	Made corrections and clarifications to Source Code check list.	SW Engineering team	30-Jul-15	NA	NA	Released
1.02	updated Davinci, MDD, and Polyspace/QAC tabs	SW Engineering team	30-Jul-15	NA	NA	Released
1.03	Aligned to portal version guidelines	Umesh Sambhari	21-Nov-17	NA	NA	Released
2.00	Summary sheet template: Changed title to indicate Implementation Peer Review Corrected and/or clarified mouse hover comments, added instructions, renamed some fields. Changed the default setting to "No" on the items reviewed	SW Engineering team	29-Nov-17	Lonnie Newton, Steven Horwath, Kevin Smith, Lucas Wendling, Vinod Shankar	NA	Released
	Source code template: Removed hyperlink for naming conventions, corrected name of naming conventions document, added version field for naming conventions document. Changed item about requirements tags to reflect that they should be removed Added clarification that all combinations of conditionally compiled code must be checked Item about accurately implementing SWC Design is modified and a new item added, both to clarify where to look when determining needed changes. Added point for version of common naming conventions Reworded multiple items for clarity	SW Engineering team	29-Nov-17
	Synergy project template: added items for file/folder structure added point on .gpj file in tools folder	SW Engineering team	29-Nov-17
	Davinci files template: Clarified the StdDef item Added new item for OBSOLETE Clarified item on datadict.m comparison Removed the references to .m file helper tool Updated to reflect that all component should now use only implementation data types Added points on PIMs and NVMs	SW Engineering team	29-Nov-17
	All template tabs: Added/clarified/removed mouse hover comments. Updated Review Board section Removed the gridlines from all tabs Updated titles to say "Nexteer SWC Implementation Peer Review" Changed all occurences of "FDD" to "SWC Design"	SW Engineering team	29-Nov-17

4 - DiagcMgrProxy_MDD

Module Design Document

For

Diagnostic Manager Proxy

VERSION: 5.0

DATE: 29-JUN-2017

Prepared By:

Shruthi Raghavan

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

Revision History

Sl. No.	Description	Author	Version	Date
1	ES101A_DiagcMgr_Design version 2 implementation	SB	1.0	11-Mar-2016
2	ES101A_DiagcMgr_Design version 4 implementation	SB	2.0	22-Jun-2016
3	Added new DET in Init1	SB	3.0	02-Dec-2016
4	Added new runnable SetNtcStsAndSnpshtData.	SR	4.0	21-Apr-2017
5	Added unit test considerations per EA4#9649	SR	5.0	29-Jun-2017

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

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	MDD Guidelines	See process v04.04.02 document from eRoom here
2	EA4 Software Naming Conventions	See process v04.04.02 document from eRoom here
3	Coding standards	See process v04.04.02 document from eRoom here
4	ES101A_DiagcMgr_Design	See Synergy Design Subproject Version

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

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 Name

Element Name

User Defined Type

Legal Range

(min)

Legal Range

(max)

Refer DiagcMgr_MDD

Variable definition for enumerated types

Enum Name	Element Name	Value
N/A

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

< All program specific constants will be defined in detail >

Local

Constant Name	Resolution	Units	Value
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 Name	Resolution	Value	Software Segment
Refer DiagcMgr_MDD

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

INIT: DiagcMgrPROXYAPPLXInit1

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

ErrorID ‘0’ is ensuring if DTCIDX value in fault response table is set to have value larger than the total number of DTCs in the code configuration.

Design Rationale

PERIODIC FUNCTIONS

Per: diagcmgrPROXYAPPLXPer1

Design Rationale

Design rationale for the subblock:
DiagcMgrProxyApplXPer1/Clear All NTCs/For Number of NTCs in NtcInfoAryX/Clear the NTCs that are active

This block clears the NTCs that are active and Not Status Locked This Ignition Cycle.
It also clears the NTCs that are NOT active from history even if they are Status Locked This Igniton Cycle

In the case of an invalid aging counter, the status of the NTC must be set to TestNotCompleteThisIgnitionCycle.

MC/DC Coverage Can be Achieved:

The above is verified to not be a MC/DC coverage issue
The second condition when reached by an invalid aging counter can still check whether the status locked and test complete conditions individually affect it.

Interrupt Functions

None

Server Runnable Functions

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.

SetNtcStsAndSnpshtDataX_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

Per the FDD author, safety critical data is protected in an exclusive area but there is a possibility of corruption of non critical data.
Refer to Design Rationale section on the top level of DiagcMgrProxy Simulink model.

UNIT TEST CONSIDERATION

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.
Low Path Coverage can be justified in the notes for now, if the reason is due to Configurable code in the component.

Note: Continuous improvement CR EA4#9630 has been written to modify the contract folder header files to allow better coverage in unit test.

Appendix

None