Sr. No.	Title	Version
1	EA4 Software Naming Conventions.doc	01.00.00
2	Software Design and Coding Standards.doc	2.1
3	ES250B_BattVltg_Design	See Synergy subproject version

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

See DataDict.m file

Required Global Data Outputs

See DataDict.m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
BattVltgInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
BattVltgPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes

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

Usage

Feature	RAM	ROM

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

1.2 - BattVltg_MDD

Module Design Document

For

BattVltg

May 18, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Nick Saxton,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	N. Saxton	1.0	18-May-2016

Table of Contents

1 BattVltg High-Level Description 4

2 Design details of software module 5

2.1 Graphical representation of BattVltg 5

2.2 Data Flow Diagram 5

2.2.1 Component level DFD 5

2.2.2 Function level DFD 5

3 Constant Data Dictionary 6

3.1 Program (fixed) Constants 6

3.1.1 Embedded Constants 6

4 Software Component Implementation 7

4.1 Sub-Module Functions 7

4.1.1 Per: BattVltgPer1 7

4.1.1.1 Design Rationale 7

4.1.1.2 Store Module Inputs to Local copies 7

4.1.1.3 (Processing of function)……… 7

4.1.1.4 Store Local copy of outputs into Module Outputs 7

4.2 Server Runables 7

4.3 Interrupt Functions 7

4.4 Module Internal (Local) Functions 7

4.5 GLOBAL Function/Macro Definitions 7

5 Known Limitations with Design 8

6 UNIT TEST CONSIDERATION 9

Appendix A Abbreviations and Acronyms 10

Appendix B Glossary 11

Appendix C References 12

BattVltg High-Level Description

Refer FDD

Design details of software module

Graphical representation of BattVltg

Data Flow Diagram

Refer FDD

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Units	Value
BATTVLTGNOCORRLN	CNT	0
BATTVLTGCORRLNSTS1	CNT	1
BATTVLTGCORRLNSTS2	CNT	2
Refer .m file for other constants

Software Component Implementation

Sub-Module Functions

The sub-module functions are grouped based on similar functionality that needs to be executed in a given “State” of the system (refer States and Modes). For a given module, the MDD will identify the type and number of sub-modules required. The sub-module types are described below.

Per: BattVltgPer1

Design Rationale

Refer FDD

Store Module Inputs to Local copies

(Processing of function)………

Store Local copy of outputs into Module Outputs

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	EA4 Software Naming Conventions.doc	01.00.00
4	Software Design and Coding Standards.doc	2.1
5	ES250B_BattVltg_Design	See Synergy subproject version

1.3 - BattVltg_PeerReview

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES250B_BattVltg_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. 1.0.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. Nick Saxton

Work CR ID:

EA4#5643

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci Files

Comments:

Initial version

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:

Nick Saxton

Review Date :

05/18/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

N/A

Comments:

versions (If available)

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

Initial version

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

No display variables

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Nick Saxton

Review Date :

05/18/16

Component Type :

Application

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

BattVltg.c

Source File Revision:

1

Header File Name:

N/A

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

MDD Name:

BattVltg_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

ES250B_BattVltg_Design

Revision:

1.0.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

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

Yes

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

No non-RTE code

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

No loops

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

No divides

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

No divides or modulus operations

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

No typecasting

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]

No float to unsigned conversion

All conversions between signed and unsigned

N/A

Comments:

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

No signed to unsigned conversions

All pointer dereferencing protects against

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

Yes

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:

Nick Saxton

Review Date :

05/18/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

BattVltg_MDD.docx

MDD Revision:

1

Source File Name:

BattVltg.c

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

N/A

Comments:

Initial version

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

No design exceptions

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

No design rationale needed

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

No differences between FDD and implementation

All Unit Test Considerations have been described

N/A

Comments:

No unit test considerations

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:

Nick Saxton

Review Date :

05/18/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

BattVltg.c

Source File Revision:

1

Source File Name:

Source File Revision:

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Initial version

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Nick Saxton

Review Date :

05/18/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

Initial version

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:

Nick Saxton

Review Date :

05/18/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

1.4 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
ES250B	65	BattVltg.c	BattVltgPer1	156	I
ES250B	48	BattVltg.c	BattVltgPer1	157	I
ES250B	49	BattVltg.c	BattVltgPer1	158	I
ES250B	51	BattVltg.c	BattVltgPer1	190	I
ES250B	77	BattVltg.c	BattVltgPer1	170-174	I
ES250B	75	BattVltg.c	BattVltgPer1	187	I
ES250B	73	BattVltg.c	BattVltgPer1	177-180	I
ES250B	72	BattVltg.c	BattVltgInit1	106-108	I
ES250B	78	BattVltg.c	BattVltgPer1	163-167	I

2 - Component Implementation

Component Implementation

Component Documentation

2.1 - BattVltgCorrln_IntegrationManual

Integration Manual

For

BattVltgCorrln

VERSION: 2.0

DATE: 27-Jun-2017

Prepared By:

Brionna Spencer,

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	N. Saxton	1.0	25-May-2016
2	Listed missing memory section in 7.1 Mapping.	B. Spencer	2.0	27-Jun-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	FDD – ES259B Battery or Switched Voltage Correlation	See Synergy subproject version
2	EA4 Software Naming Conventions	01.01.00
3	Software Design and Coding Standards	2.1

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer to DataDict.m file in the FDD.

Required Global Data Outputs

Refer to DataDict.m file in the FDD.

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
BattVltgCorrlnInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
BattVltgCorrlnPer1	None	RTE (2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
BattVltgCorrln_START_SEC_CODE

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

Usage

Feature	RAM	ROM

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

2.2 - BattVltgCorrln_MDD

Module Design Document

For

BattVltgCorrln

27-Jun-2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Brionna Spencer,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	N. Saxton	1.0	7-Jun-2016
Updated the graphical representation, added design rationale for BattVltgCorrlnPer1, and updated the documentation for modified local functions (i.e. DetInstCorrln, DetIdptSig, and DetCorrlnSts).	B. Spencer	2.0	27-Jun-2017

Table of Contents

1 BattVltgCorrln & High-Level Description 4

2 Design details of software module 5

2.1 Graphical representation of BattVltgCorrln 5

2.2 Data Flow Diagram 6

2.2.1 Component level DFD 6

2.2.2 Function level DFD 6

3 Constant Data Dictionary 7

3.1 Program (fixed) Constants 7

3.1.1 Embedded Constants 7

4 Software Component Implementation 8

4.1.1 Sub-Module Functions 8

4.1.2 Interrupt Service Routines 8

4.1.3 Server Runnable Functions 8

4.1.4 Module Internal (Local) Functions 8

4.1.5 Transition Functions 10

5 Known Limitations with Design 11

6 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

BattVltgCorrln & High-Level Description

Refer FDD

Design details of software module

Graphical representation of BattVltgCorrln

Data Flow Diagram

Component level DFD

N/A

Function level DFD

N/A

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
BATTVLTGIDPTSIGMIN_CNT_U08	None	Cnt	0
BATTVLTGIDPTSIGMAX_CNT_U08	None	Cnt	2

* Refer FDD for other constant definition

Software Component Implementation

Sub-Module Functions

Initialization sub-module {_Init()}

BattVltgCorrlnInit1

Design Rationale

Refer to FDD

Store module inputs to local copies

Refer to FDD

(Processing of function)……

Refer to FDD

Store local copy of outputs into module outputs

Refer FDD

Periodic sub-module {_Per()}

BattVltgCorrlnPer1

Design Rationale

Refer to FDD

Note the BattAndSwdVltgPassed temporary variable in the FDD was renamed to BattVltgAndSwd1NotFailed because the ‘no result’ case is also considered in the logic.

Store module inputs to local copies

Refer to FDD

(Processing of function)……

Refer to FDD

Store local copy of outputs into module outputs

Refer FDD

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	DetInstCorrln	Type	Min	Max
Arguments Passed	BattVltg_Volt_T_f32	float32	0	40
	BattVltgSwd1_Volt_T_f32	float32	0	40
	DiagcStsIvtr1Inactv_Cnt_T_logl	boolean	FALSE	TRUE
	*BattVltgAndSwd1Ok_Cnt_T_logl	boolean	FALSE	TRUE

	*UseSwdVltg_Cnt_T_logl	boolean	FALSE	TRUE
	*UseBattVltg_Cnt_T_logl	boolean	FALSE	TRUE
	*Ntc0x03CQlfrSts_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	*Ntc0x044QlfrSts_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
Return Value	SwdVltgLimd_Cnt_T_logl	boolean	FALSE	TRUE

Description

Refer “Determine Instantaneous Correlation” subsystem in FDD.

Local Function #2

Function Name	DetIdptSig	Type	Min	Max
Arguments Passed	Ntc0x03CQlfrSts_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	Ntc0x044QlfrSts_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	*BattVltgAndSwd1NotFailed_Cnt_T_logl	boolean	FALSE	TRUE

Return Value	BattVltgCorrlnIdptSig_Cnt_T_u08	uint8	0	2

Description

This function implements the “Determine Independent Signals” subsystem in the model.

Local Function #3

Function Name	DetCorrlnSts	Type	Min	Max
Arguments Passed	BattVltgAndSwd1NotFailed_Cnt_T_logl	boolean	FALSE	TRUE

	BattVltgAndSwd1Ok_Cnt_T_logl	boolean	FALSE	TRUE

	UseSwdVltg_Cnt_T_logl	boolean	FALSE	TRUE
	UseBattVltg_Cnt_T_logl	boolean	FALSE	TRUE
	*DftBrdgVltgActv_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	BattSwdVltgCorrlnSts_Cnt_T_u08	uint8	0	2

Description

This function implements the “Determine Correlation Status” subsystem in the model.

Local Function #4

Function Name	BattVltgDiag	Type	Min	Max
Arguments Passed	BattVltg_Volt_T_f32	float32	0	40
	InhbBattVltgDiagc_Cnt_T_logl	boolean	FALSE	TRUE

Description

Implements “Battery Voltage Diagnostics” subsystem.

Local Function #5

Function Name	RngChk	Type	Min	Max
Arguments Passed	BattVltg_Volt_T_f32	float32	0	40
	BattVltgSwdMax_Volt_T_f32	float32	0	40
Return Value	TestLgc_Cnt_T_logl	boolean	FALSE	TRUE

Description

Implements “Range Check” block in the model. Created to reduce cyclomatic complexity and static path count.

Transition Functions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

None

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	EA4 Software Naming Conventions	01.01.00
4	Software Design and Coding Standards	2.1
5	FDD – ES259B Battery or Switched Voltage Correlation	See Synergy subproject version

2.3 - BattVltgCorrln_PeerReview

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES259B_BattVltgCorrln_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. ES259B_BattVltgCorrln_Impl_1.2.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. Matthew Leser

Work CR ID:

EA4#16065

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci 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:

Matthew Leser

Review Date :

11/01/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

N/A

Comments:

For components not using application data types, do all

N/A

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

N/A

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

removed

All sender/receiver port read/writes using direct

N/A

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

11/01/17

Component Type :

Application

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

BattVltgCorrln.c

Source File Revision:

3

Header File Name:

N/A

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

MDD Name:

BattVltgCorrln_MDD.doc

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

ES259B_BattVltgCorrln_Design

Revision:

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

N/A

Comments:

all outputs are initialized prior to being written

Requirements Tracability tags in code match the

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

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

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

N/A

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

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:

Matthew Leser

Review Date :

11/01/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

BattVltgCorrln.c

Source File Revision:

3

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Unreachable code warning with respect to Lim_u08 is okay; output limit is required by design and coding standards.

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:

Matthew Leser

Review Date :

11/01/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

3 - Component Implementation

Component Implementation

Component Documentation

3.1 - CurrMeas_IntegrationManual

Integration Manual

For

CurrMeas

VERSION: 1.0

DATE: 18-May-2017

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.	Description	Author	Version	Date
1	Initial version	Krzysztof Byrski	1.0	18-May-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	EA4 Software Naming Conventions	01.01.00
2	Software Design and Coding Standards	2.1
3	ES200B_CurrMeas_Design	See Synergy Sub Project Version

Dependencies

SWCs

Module	Required Feature
DF001A_FltInj	Header file: FltInj.h
ES999A_ElecGlbPrm	Header file: ElecGlbPrm.h

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

CurrMeasPer2

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
FLTINJENA	Takes values STD_ON or STD_OFF

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

See FDD DataDict.m.

Required Global Data Outputs

See FDD DataDict.m.

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
CurrMeasInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
CurrMeasPer1	None	RTE(2ms)
CurrMeasPer2	None	ISR(2 * MtrCtrlISR)
CurrMeasPer3	None	RTE(2ms)
CurrMeasEolGainReq_Oper	None	RTE(Event)
CurrMeasEolGainStsReq_Oper	None	RTE(Event)
CurrMeasEolOffsReq_Oper	None	RTE(Event)
CurrMeasEolOffsStsReq_Oper	None	RTE(Event)
CurrMeasGainReadReqSngIvtr_Oper	None	RTE(Event)
CurrMeasGainWrReqSngIvtr_Oper	None	RTE(Event)
CurrMeasOffsReadReqSngIvtr_Oper	None	RTE(Event)
CurrMeasOffsWrReqSngIvtr_Oper	None	RTE(Event)

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
CDD_CurrMeas_START_SEC_CODE	Functions
CDD_CurrMeas_MotCtrl_START_SEC_CODE	Functions

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

*See DataDict.m

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

3.2 - CurrMeas_MDD

Module Design Document

For

CurrMeas

Oct 16, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Krzysztof Byrski	1.0	19-May-2017
Fixed anomaly EA4#13330 by using required NVM blocks as applicable	Krishna Anne	2.0	16-Oct-17

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 CurrMeas & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of CurrMeas 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: CurrMeasInit1 9

5.1.2 Per: CurrMeasPer1 9

5.1.3 Per: CurrMeasPer2 9

5.1.4 Per: CurrMeasPer3 10

5.2 Server Runables 11

5.2.1 CurrMeasEolGainReq_Oper 11

5.2.2 CurrMeasEolGainStsReq_Oper 11

5.2.3 CurrMeasEolOffsReq_Oper 11

5.2.4 CurrMeasEolOffsStsReq_Oper 11

5.2.5 CurrMeasGainReadReqSngIvtr_Oper 11

5.2.6 CurrMeasGainWrReqSngIvtr_Oper 11

5.2.7 CurrMeasOffsReadReqSngIvtr_Oper 12

5.2.8 CurrMeasOffsWrReqSngIvtr_Oper 12

5.3 Interrupt Functions 13

5.4 Module Internal (Local) Functions 13

5.4.1 OffsetCalibration 13

5.4.2 GainCalibration 14

5.4.3 RangeChkWIABC 14

5.4.4 ProtocolChkENABC 15

5.4.5 CalcMotCurrMotAgCorrd 15

5.4.6 CalMotCurrCorrdABC 15

5.4.7 OffsCalcABC 16

5.5 GLOBAL Function/Macro Definitions 17

6 Known Limitations with Design 18

7 UNIT TEST CONSIDERATION 19

Appendix A Abbreviations and Acronyms 20

Appendix B Glossary 21

Appendix C References 22

Introduction

Purpose

Module Design Document for ES200B_CurrMeas.

Scope

The following definitions are used throughout this document:

Shall: indicates a mandatory requirement without exception in compliance.
Should: indicates a mandatory requirement; exceptions allowed only with documented justification.
May: indicates an optional action.

CurrMeas & High-Level Description

Refer FDD.

Design details of software module

Graphical representation of CurrMeas

Data Flow Diagram

Refer FDD

Component level DFD

None

Function level DFD

None

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
CALPROCNOTSTRTD_CNT_U08	1	Cnt	0
CALPROCSTRTD_CNT_U08	1	Cnt	1
CALPROCPASS_CNT_U08	1	Cnt	2
CALPROCPHAABCEOLOUTOFRNG_CNT_U08	1	Cnt	4
CALPROCVEHSPDCNDNOTMET_CNT_U08	1	Cnt	16
CALPROCMOTVELMRFCNDNOTMET_CNT_U08	1	Cnt	64
VEHSPDCDNNOTMET_CNT_U08	1	Cnt	4
MOTVELMRFCDNNOTMET_CNT_U08	1	Cnt	8
DIAGCSTSINVTRINACTV_CNT_U08	1	Cnt	16
FAILDATENA_CNT_U08	1	Cnt	2
FAILDATWRMININ_CNT_U08	1	Cnt	3
INVTRINACTV_CNT_U08	1	Cnt	8
DIFOFFSRNGCHKMAX_VOLT_F32	Single precision float	Volt	1.0
DEGREES30_MOTRAD_F32	Single precision float	MotRad	0.5236
MAXCURRCORRD_AMPR_F32	Single precision float	Ampr	200.0
PHAONTIBCOK_CNT_U08	1	Cnt	0x03
PHAONTIACOK_CNT_U08	1	Cnt	0x05
PHAONTIABOK_CNT_U08	1	Cnt	0x06
PHAONTIABCOK_CNT_U08	1	Cnt	0x07
PHAONTIA_CNT_U08	1	Cnt	0x04
PHAONTIB_CNT_U08	1	Cnt	0x02
PHAONTIC_CNT_U08	1	Cnt	0x01
NANOSECTOSEC_ULS_F32	Single precision float	Uls	0.000000001

Software Component Implementation

Sub-Module Functions

Init: Init1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: Per1

Design Rationale

Refer FDD

Store Module Inputs to Local copies

Refer FDD

(Processing of function)………

Refer FDD

Store Local copy of outputs into Module Outputs

Refer FDD

Per: Per2

Design Rationale

Refer FDD

Store Module Inputs to Local copies

Refer FDD

(Processing of function)………

Refer FDD

Store Local copy of outputs into Module Outputs

Refer FDD

Per: Per3

Design Rationale

Refer FDD

Store Module Inputs to Local copies

Refer FDD

(Processing of function)………

Refer FDD

Store Local copy of outputs into Module Outputs

Refer FDD

Server Runables

CurrMeasEolGainReq_Oper

Design Rationale

Refer FDD

(Processing of function)………

Refer FDD

CurrMeasEolGainStsReq_Oper

Design Rationale

Refer FDD

(Processing of function)………

Refer FDD

CurrMeasEolOffsReq_Oper

Design Rationale

Refer FDD

(Processing of function)………

Refer FDD

CurrMeasEolOffsStsReq_Oper

Design Rationale

Refer FDD

CurrMeasGainReadReqSngIvtr_Oper

Design Rationale

Refer FDD

(Processing of function)………

Refer FDD

CurrMeasGainWrReqSngIvtr_Oper

Design Rationale

Refer FDD

(Processing of function)………

Refer FDD

CurrMeasOffsReadReqSngIvtr_Oper

Design Rationale

Refer FDD

(Processing of function)………

Refer FDD

CurrMeasOffsWrReqSngIvtr_Oper

Design Rationale

Refer FDD

(Processing of function)………

Refer FDD

Interrupt Functions

None

Module Internal (Local) Functions

OffsetCalibration

Function Name	OffsetCalibration	Type	Min	Max
Arguments Passed	MotCurrAdcVlyA_Volt_T_f32	float32	0.0	5.0
	MotCurrAdcVlyB_Volt_T_f32	float32	0.0	5.0
	MotCurrAdcVlyC_Volt_T_f32	float32	0.0	5.0
	MotVelMrf_MotRadPerSec_T_f32	float32	-1350.0	1350.0
	VehSpd_Kph_T_f32	float32	0.0	511.0
	VehSpdVld_Cnt_T_logl	boolean	FALSE	TRUE
	BrdgVltg_Volt_T_f32	float32	6.0	26.5
	DiagcStsIvtr1Inactv_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	N/A	-	-	-

Design Rationale

Refer FDD

Processing

Refer FDD

GainCalibration

Function Name	GainCalibration	Type	Min	Max
Arguments Passed	MotCurrEolOffsProcFlg_Cnt_T_logl	boolean	FALSE	TRUE
	MotCurrAdcVlyA_Volt_T_f32	float32	0.0	5.0
	MotCurrAdcVlyB_Volt_T_f32	float32	0.0	5.0
	MotCurrAdcVlyC_Volt_T_f32	float32	0.0	5.0
	MotVelMrf_MotRadPerSec_T_f32	float32	-1350.0	1350.0
	MotCurrOffsZeroAvrgA_Volt_T_f32	float32	0.0	5.0
	MotCurrOffsZeroAvrgB_Volt_T_f32	float32	0.0	5.0
	MotCurrOffsZeroAvrgC_Volt_T_f32	float32	0.0	5.0
	VehSpd_Kph_T_f32	float32	0.0	511.0
	VehSpdVld_Cnt_T_logl	boolean	FALSE	TRUE
	DiagcStsIvtr1Inactv_Cnt_T_logl	boolean	FALSE	TRUE
	MotCurrEolCalStPrev_Cnt_T_enum	MotCurrEolCalSt2	0	8
Return Value	N/A	-	-	-

Design Rationale

Refer FDD

Processing

Refer FDD

RangeChkWIABC

Function Name	RangeChkWIABC	Type	Min	Max
Arguments Passed	MotCurrAdcVlyA_Volt_T_f32	float32	0.0	5.0
	MotCurrAdcVlyB_Volt_T_f32	float32	0.0	5.0
	MotCurrAdcVlyC_Volt_T_f32	float32	0.0	5.0
Return Value	InRng_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

Refer FDD

Processing

Refer FDD

ProtocolChkENABC

Function Name	ProtocolChkENABC	Type	Min	Max
Arguments Passed	N/A	-	-	-
Return Value	ProtocolChkEn_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

Refer FDD

Processing

Refer FDD

CalcMotCurrMotAgCorrd

Function Name	CalcMotCurrMotAgCorrd	Type	Min	Max
Arguments Passed	N/A	-	-	-
Return Value	MotCtrlCurrMeasMotAgCorrd_Rad_T_f32	float32	-0.7666	6.2832

Design Rationale

Refer FDD

Processing

Refer FDD

CalMotCurrCorrdABC

Function Name	CalMotCurrCorrdABC	Type	Min	Max
Arguments Passed	MotCurrOffsA_Volt_T_f32	float32	-1892868,5	1892873,5
	MotCurrOffsA_Volt_T_f32	float32	-1892868,5	1892873,5
	MotCurrOffsA_Volt_T_f32	float32	-1892868,5	1892873,5
Return Value	N/A

Design Rationale

Refer FDD

Processing

Refer FDD

OffsCalcABC

Function Name	OffsCalcABC	Type	Min	Max
Arguments Passed	N/A
Return Value	MotCurrOffsA_Volt_T_f32	float32	-1892868,5	1892873,5
	MotCurrOffsB_Volt_T_f32	float32	-1892868,5	1892873,5
	MotCurrOffsC_Volt_T_f32	float32	-1892868,5	1892873,5

Design Rationale

Refer FDD

Processing

Refer FDD

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description
-	-

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions	01.01.00
4	Software Design and Coding Standards	2.1
5	ES200B_CurrMeas_Design	See Synergy Sub Project Version

3.3 - CurrMeas_Review

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
CDD_CurrMeas_MotCtrl
MDD
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES200B_CurrMeas_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. ES200B_CurrMeas_Impl_2.1.0

Change Owner:

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

Work CR ID:

EA4#15188

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci 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:

Latest versions

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:

Krishna Anne

Review Date :

10/16/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Krishna Anne

Review Date :

10/16/17

Component Type :

CDD

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_CurrMeas.c

Source File Revision:

4

Header File Name:

CDD_CurrMeas.h

Header File Revision:

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

MDD Name:

CurrMeas_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES200B_CurrMeas_Design

Revision:

2.1.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

N/A for changes

for function names

N/A

Comments:

N/A for changes

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

N/A for changes

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

N/A for EA4

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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]

N/A for changes

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]

N/A for changes

Memory mapping for non-RTE code

Yes

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

N/A for changes

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

N/A for changes

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

N/A for changes

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

N/A for changes

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]

N/A for changes

All conversions between signed and unsigned

N/A

Comments:

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

N/A for changes

All pointer dereferencing protects against

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

N/A

Comments:

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

N/A for changes

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:

Krishna Anne

Review Date :

10/16/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: CDD_CurrMeas_MotCtrl

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_CurrMeas_MotCtrl.c

Source File Revision:

3

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:

CurrMeas_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES200B_CurrMeas_Design

Revision:

2.1.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

N/A

Comments:

N/A for changes

for constant names

N/A

Comments:

N/A for changes

for function names

N/A

Comments:

N/A for changes

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

N/A for changes

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

N/A for EA4

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

N/A

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

N/A

Comments:

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

Function comment blocks are per standards and

N/A

Comments:

contain correct information: [N43]

N/A for changes

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]

N/A for changes

Memory mapping for non-RTE code

Yes

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

N/A for changes

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

N/A for changes

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

N/A for changes

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

N/A for changes

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]

N/A for changes

All conversions between signed and unsigned

N/A

Comments:

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

N/A for changes

All pointer dereferencing protects against

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

N/A

Comments:

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

N/A for changes

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:

Krishna Anne

Review Date :

10/16/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

CurrMeas_MDD

MDD Revision:

2

Source File Name:

CDD_CurrMeas.c

Source File Revision:

4

Source File Name:

CDD_CurrMeas_MotCtrl.c

Source File Revision:

3

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

Yes

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Krishna Anne

Review Date :

10/16/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_CurrMeas.c

Source File Revision:

4

Source File Name:

CDD_CurrMeas_MotCtrl.c

Source File Revision:

3

Source File Name:

-

Source File Revision:

-

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 NA

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

Not changed since previous version

100% Compliance to the EA4 Static Analysis

Yes

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

Not changed since previous version

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

Not changed since previous version

and Coding Standards rule [N47]

General Notes / Comments:

10/16/2017: Krishna : Cyclomatic complexity was beyond the acceptable limits since the beginning of this Impl; This needs to be fixed in a next update.

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:

Krishna Anne

Review Date :

10/16/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

4 - Component Implementation

Component Implementation

Component Documentation

4.1 - CurrMeasArbn_ Review

Overview

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES208A_CurrMeasArbn_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. 1.6.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. Selva Sengottaiyan

Work CR ID:

EA4#4752

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci 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:

Selva

Review Date :

03/20/16

Lead Peer Reviewer:

Rijvi

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_CurrMeasArbn_MotCtrl.c

Source File Revision:

5

Header File Name:

CDD_CurrMeasArbn.h

Header File Revision:

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

MDD Name:

CurrMeasArbn_MDD

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

ES208A_CurrMeasArbn_Design

Revision:

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

Yes

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

N/A

Comments:

all outputs are initialized prior to being written

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

Yes

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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:

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

N/A

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

N/A

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

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

N/A

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:

Reviewed only for the changes

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:

Selva

Review Date :

03/20/16

Lead Peer Reviewer:

Rijvi

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

CurrMeasArbn_MDD

MDD Revision:

3

Source File Name:

CDD_CurrMeasArbn.c

Source File Revision:

2

Source File Name:

CDD_CurrMeasArbn_MotCtrl.c

Source File Revision:

4

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

Yes

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Selva Sengottaiyan

Review Date :

09/17/15

Lead Peer Reviewer:

Kathleen

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_CurrMeasArbn_MotCtrl.c

Source File Revision:

4

Source File Name:

CDD_CurrMeasArbn.c

Source File Revision:

2

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

1.01.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 Not in synergy

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Selva

Review Date :

03/20/16

Lead Peer Reviewer:

Rijvi

Approved by Reviewer(s):

Yes

Other Reviewer(s):

4.2 - CurrMeasArbn_IntegrationManual

Integration Manual

For

CURRENT MEASUREMENT ARBITRATION

VERSION: 1.2

DATE: 14-APR-2015

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.	Description	Author	Version	Date
1	Initial version	Selva Sengottaiyan	1.0	14-Apr-2015

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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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

Sr. No.	Title	Version
<1>	FDD - ES208A Current Measurement Arbitration	See synergy subversion

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

CurrMeasArbnPer1()

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
N/A

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
CurrMeasArbnInit1	None	RTE

Runnable	Scheduling Requirements	Trigger
CurrMeasArbnPer1	None	MOTCTRL ISR*2

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotCtrl_START_SEC_CODE	Code section for Motor Control scheduled functions

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

Non RTE NvM Blocks

Block Name
None

Note : Size of the NVM block if configured in developer

RTE NvM Blocks

Block Name
None

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

4.3 - CurrMeasArbn_MDD

Module Design Document

For

Current Measurement Arbitration

Mar 18, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

SEPG,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	Selva	1.0	14- Apr-2015
Updated for Anomoly EA4#1589 . Combined MDD for both sources files	Selva	2.0	17 -Sep 2015
Updated for Anomoly EA4#2989	Selva	3.0	18 -Mar 2016

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 Current Measurement Arbitration & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of Current Measurement Arbitration 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: CurrMeasArbnInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.1.3 Per: 9

5.1.1.4 CurrMeasARBNPer1 9

5.1.1.5 Design Rationale 9

5.1.1.6 Store Module Inputs to Local copies 9

5.1.1.7 (Processing of function)……… 9

5.1.1.8 Store Local copy of outputs into Module Outputs 9

5.2 Server Runables 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 9

5.5 Local Function/Macro Definitions 9

5.5.1 Local Function #1 SigAvlCheck 9

5.5.1.1 Description 10

5.5.2 Local Function #2 ParkTransformation 10

5.5.2.1 Description 10

5.6 GLOBAL Function/Macro Definitions 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 16

Introduction

Purpose

None

Scope

None

Current Measurement Arbitration & High-Level Description

The component contains two source files, both described in this MDD: CDD_ CurrMeasArbn.c contains the RTE init runnable; CDD_CurrMeasArbn_MotCtrl.c contains the motor control runnable.

Refer the Design for high level Description

Design details of software module

None

Graphical representation of Current Measurement Arbitration

Data Flow Diagram

Component level DFD

None

Function level DFD

None

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value


MAXVALSIGSTALL_CNT_U08	1	Cnt	255

Refer DataDict.m file for other local constants	Refer DataDict.m file for other local constants	Refer DataDict.m file for other local constants	Refer DataDict.m file for other local constants

Software Component Implementation

Sub-Module Functions

Init: CurrMeasArbnInit1

Design Rationale

Init1 function is created so that it will allow a RTE model to be created in the AUTOSAR tools which allows Per-Instance Memory and calibration definition needs. The initialization function is doing nothing

Module Outputs

None

Per:

CurrMeasARBNPer1

Design Rationale

Inputs and outputs are globals since its non RTE (MotorControl ISR) function.

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

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function/Macro Definitions

Local Function #1 SigAvlCheck

Function Name	SigAvlCheck	Type	Min	Max
Arguments Passed	CurrMeasSigQlfr_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	CurrMeasSigRollgCntr_Cnt_T_u08	uint8	0	255
	CurrMeasSigCorrlnChk_Cnt_T_u08	uint8	0	255
	*PrevCurrMeasSigRollgCntr_Cnt_T_u08	uint8	0	255
	*CurrMeasSigStall_Cnt_T_u08	uint8	0	255
Return Value	SignalAvailable_Cnt_T_logl	boolean	FALSE	TRUE

Description

Refer FDD.

Local Function #2 ParkTransformation

Function Name	CurrMeasCorrlnChk	Type	Min	Max
Arguments Passed	PhaseAMotCurrCorrd_Ampr_T_f32	float32	-200	200
	PhaseBMotCurrCorrd_Ampr_T_f32	float32	-200	200
	PhaseCMotCurrCorrd_Ampr_T_f32	float32	-200	200
	MotCtrlCurrMeasMotAgCorrd_Rad_T_f32	float32	-6.282	6.282
	MotCtrlMotElecMeclPolarity_Uls_T_s08*	sint8	-1	1
Return Value	MotCurrDax_Ampr_T_f32	float32	-200	200
	MotCurrQax_Ampr_T_f32	float32	-200	200

Description

Refer FDD.

MotCtrlMotElecMeclPolarity_Cnt_T_s08* takes two values (-1 and 1)

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD - ES208A Current Measurement Arbitration	See synergy subversion

4.4 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
ES208A	216	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	105-192	I
ES208A	217	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	153-157	I
ES208A	214	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	115	I
ES208A	215	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	114	I
ES208A	212	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	117	I
ES208A	213	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	116	I
ES208A	211	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	144-148	I
ES208A	218	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	161-165	I
ES208A	219	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	132-140	I
ES208A	135	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	122-130	I
ES208A	221	CDD_CurrMeasArbn_MotCtrl.c	ParkTransformation	272,282	I
ES208A	200	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	118	I
ES208A	202	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	107	I
ES208A	205	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	106	I
ES208A	204	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	182	I
ES208A	206	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	183	I
ES208A	99	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	113	I
ES208A	102	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	110	I
ES208A	103	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	109	I
ES208A	100	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	112	I
ES208A	101	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	111	I
ES208A	104	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	108	I
ES208A	220	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	169-173	I
ES208A	15	CDD_CurrMeasArbn_MotCtrl.c	CurrMeasArbnPer1	177-181,182,183	I

5 - Component Implementation

Component Implementation

Component Documentation

5.1 - CurrMeasCorrln_IntegrationManual

Integration Manual

For

CURRENT MEASUREMENT CORRELATION

VERSION: 3.0

DATE: 07-Jun-2017

Prepared By:

Shawn Penning,

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	Nick Saxton	1.0	26-Apr-2016
2	Added FltInj point for an output	Krishna Anne	2.0	27-Jun-16
3	Added Init Runnable	Shawn Penning	3.0	06-Jun-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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

Sr. No.	Title	Version
1	FDD - ES209A Current Measurement Correlation	Refer current Synergy subproject version
2	Software Naming Conventions	1.01.00
3	Software Design and Coding Standards	2.1

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
CurrMeasCorrln	FLTINJENA should be set to STD_ON as required

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
N/A

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

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
CurrMeasCorrlnInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
CurrMeasCorrlnPer1	None	RTE 2ms

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
CurrMeasCorrln_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

Non RTE NvM Blocks

Block Name
None

Note : Size of the NVM block if configured in developer

RTE NvM Blocks

Block Name
None

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

5.2 - CurrMeasCorrln_MDD

Module Design Document

For

Current Measurement Correlation

21-Feb-2018 Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Shawn Penning,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial version	Nick Saxton	1.0	26-Apr-2016
Update per design rev. 1.6.0	Shawn Penning	2.0	23-May-2017
Update graphic design 2.0	Shawn Penning	3.0	21-Feb-2018

Table of Contents

1 Current Measurement Correlation & High-Level Description 5

2 Design details of software module 6

2.1 Graphical representation of Current Measurement Correlation 6

2.2 Data Flow Diagram 6

2.2.1 Component level DFD 6

2.2.2 Function level DFD 6

3 Constant Data Dictionary 7

3.1 Program (fixed) Constants 7

3.1.1 Embedded Constants 7

3.1.1.1 Local 7

4 Software Component Implementation 8

4.1 Sub-Module Functions 8

4.1.1 Initialization Functions 8

4.1.1.1 INIT 8

4.1.1.2 Design Rationale 8

4.1.1.3 Store Module Inputs to Local copies 8

4.1.1.4 (Processing of function)……… 8

4.1.1.5 Store Local copy of outputs into Module Outputs 8

4.1.2 PERIODIC FUNCTIONS 8

4.1.2.1 Per: CurrMeasCorrlnPer1 8

4.1.2.2 Design Rationale 8

4.1.2.3 Store Module Inputs to Local copies 8

4.1.2.4 (Processing of function)……… 8

4.1.2.5 Store Local copy of outputs into Module Outputs 8

4.2 Server Runables 8

4.3 Interrupt Functions 8

4.4 Module Internal (Local) Functions 9

4.5 Local Function/Macro Definitions 9

4.5.1 Local Function #1 SigAvlChk 9

4.5.1.1 Description 9

4.5.2 Local Function #2 CurrMeasCorrlnChk 9

4.5.2.1 Description 9

4.6 GLOBAL Function/Macro Definitions 9

5 Known Limitations with Design 10

6 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 15

Current Measurement Correlation & High-Level Description

Refer FDD

Design details of software module

Graphical representation of Current Measurement Correlation

Data Flow Diagram

Refer FDD

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local

Constant Name	Units	Value
CORRLNSTSABC_CNT_U08	Cnt	0x07
CURRMOTSUMLOLIM_AMPR_F32	Ampr	0.0F
CURRMOTSUMHILIM_AMPR_F32	Ampr	600.0F

Software Component Implementation

Sub-Module Functions

Initialization Functions

INIT

None

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)…

None

Store Local copy of outputs into Module Outputs

None

PERIODIC FUNCTIONS

Per: CurrMeasCorrlnPer1

Design Rationale

Refer FDD

Store Module Inputs to Local copies

Refer FDD

(Processing of function)…

Refer FDD

Store Local copy of outputs into Module Outputs

Refer FDD

Server Runnables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function/Macro Definitions

Local Function #1 SigAvlChk

Function Name	SigAvlChk	Type	Min	Max
Arguments Passed	MotCurrQlfr1_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	MotCurrRollgCntr1_Cnt_T_u08	uint8	0	255
Return Value	SigAvlABC_Cnt_T_logl	boolean	FALSE	TRUE

Description

Refer FDD.

Local Function #2 CurrMeasCorrlnChk

Function Name	CurrMeasCorrlnChk	Type	Min	Max
Arguments Passed	MotCurrCorrdA_Ampr_T_f32	float32	-200	200
	MotCurrCorrdB_Ampr_T_f32	float32	-200	200
	MotCurrCorrdC_Ampr_T_f32	float32	-200	200
	*CurrMeasLongTermCorrlnStsVldABC_Cnt_T_logl	boolean	FALSE	TRUE
	*CurrMotSumABC_Ampr_T_f32	float32	0	600
Return Value	CurrMeasImdtCorrlnStsVldABC_Cnt_T_logl	boolean	FALSE	TRUE

Description

Refer FDD.

* CurrMeasLongTermCorrlnStsVldABC_Cnt_T_logl and * CurrMotSumABC_Ampr_T_f32 are outputs of this function.

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

In Signal Availability, SigQlfr sets up 3 possible results:

0 = No Result

1 = Pass

2 = Fail

The model converts this enumerated type to uint8 and checks if less than 2 (Fail). The code differs in that it checks explicitly for No Result (SIGQLFR_NORES) or Pass (SIGQLFR_PASSD).

UNIT TEST CONSIDERATION

Continuous improvent CR EA4#12527 written for output range correction for CurrMeasCorrlnSts.Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.01.00
3	Software Naming Conventions	01.01.00
4	Software Design and Coding Standards	2.1
5	FDD – ES209A Current Measurement Correlation	See synergy subversion

5.3 - CurrMeasCorrln_PeerReview

Overview

Summary Sheet
Davinci Files
Source Code
PolySpace
MDD
Synergy Project

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

ES209B_CurrMeasCorrln_Impl

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

ES209B_CurrMeasCorrln_Impl_2.0.0

Change Owner:

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

Shawn Penning

Work CR ID:

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

EA4#15467

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

Yes

Davinci 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 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: Davinci Files

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

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

Yes

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

Input needs to be removed from

file) in all areas where arxml was changed and/or the

datadict.m. Done and design 2.1.0 baselined 2/26/18

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

N/A

Comments:

(name, data type)

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using "Write (explicit)"

Yes

Comments:

and "Read (explicit by argument)"(List justification if not)

Runnable calling frequencies match DataDict.m file

N/A

Comments:

Runnable port access matches the DataDict.m file

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Name and data type match DataDict.m file.

Per Instance Memory names and data types

Yes

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

02/26/18

Component Type :

Application

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

Shishir Holenarasipura

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

Sheet 3: Source Code

Rev 2.00

29-Nov-17

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

Source File Name:

CurrMeasCorrln.c

Source File Revision:

6

Header File Name:

N/A

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

MDD Name:

CurrMeasCorrln_MDD.docx

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

SWC Design Name:

ES209A_CurrMeasCorrln_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" 2.1.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

Yes

Comments:

for constant names

Yes

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

Yes

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.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

Change log description and CR number requires update

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

Fixed 2/26/18

Work CR number

Code accurately implements SWC Design (Document or Model)

Yes

Comments:

DataDict needs input removed

in all areas where code was changed and/or Simulink

New design 2.1.0 baselined 2/26/18

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:

Need update of design 2.0.0 to 2.1.0

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

Done see above

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:

Compile after change to line 964

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

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

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

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

02/26/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Gerald McCann

Comments:

Srikar Chintapalli

Integrator and or
SW lead:

Akilan Rathakrishnan

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

Shishir Holenarasipura

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

Sheet 4: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

CurrMeasCorrln.c

Source File Revision:

6

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

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

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

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

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

Yes

Comments:

Run with Fault Inj on and off

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Review Board:

Change Owner: Shawn Penning Review Date :

Lead Peer Reviewer: Test Approved by Reviewer(s):

Other Reviewer(s):

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

Change Owner:

Shawn Penning

Review Date :

02/26/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 5: MDD

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

CurrMeasCorrln_MDD.docx

MDD Revision:

2

Source File Name:

CurrMeasCorrln.c

Source File Revision:

6

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the SWC

N/A

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

none

General Notes / Comments:

Review Board:

Change Owner: Shawn Penning Review Date :

Lead Peer Reviewer: Test Approved by Reviewer(s):

Other Reviewer(s):

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

Change Owner:

Shawn Penning

Review Date :

02/21/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: 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:

ES209B_CurrMeasCorrln_Impl_2.1.0

naming convention

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

Need to baseline with Design v 2.1.0.

Done - Imported new design 2.1.0 on 2/26/18

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

Yes

Comments:

File/folder structure is correct per documentation in

Yes

Comments:

TL109A_SwcSuprt

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

02/26/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

6 - Component Implementation

Component Implementation

Component Documentation

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

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

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

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

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

No

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:

11

Source File Name:

DiagcMgr.c

Source File Revision:

18

Source File Name:

DiagcMgr_private.c

Source File Revision:

4

Source File Name:

DiagMgrNonRte.c

Source File Revision:

8

Source File Name:

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

Source File Revision:

8

Source File Name:

DiagcMgrProxyAppl3.c

Source File Revision:

9

Source File Name:

DiagcMgrProxyAppl6.c

Source File Revision:

11

Source File Name:

DiagcMgrProxyAppl10.c

Source File Revision:

11

Source File Name:

DiagcMgrStub.c

Source File Revision:

4

Source File Name:

DiagcMgr_Cfg.c.tt

Source File Revision:

8

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:

18

Source File Name:

DiagcMgr_private.c

Source File Revision:

4

Source File Name:

DiagMgrNonRte.c

Source File Revision:

8

Source File Name:

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

Source File Revision:

8

Source File Name:

DiagcMgrProxyAppl3.c

Source File Revision:

9

Source File Name:

DiagcMgrProxyAppl6.c

Source File Revision:

11

Source File Name:

DiagcMgrProxyAppl10.c

Source File Revision:

11

Source File Name:

DiagcMgrStub.c

Source File Revision:

4

Source File Name:

DiagcMgr_Cfg.c.tt

Source File Revision:

8

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

No

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

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

7 - Component Implementation

Component Implementation

Component Documentation

7.1 - DualEcuIdn_IntegrationManual

Integration Manual

For

DualEcuIdn

VERSION: 2.0

DATE: 28-Mar-2017

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.	Description	Author	Version	Date
1	Initial version	Avinash James	1.0	10 -Jan-2017
2	Corrected to say No specific include path	Shawn Penning	2.0	28-Mar-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional 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	FDD – ES011A DualEcuIdn	See Synergy subproject version
2	Software Naming Conventions	Process 04.02.01
3	Software Coding Standards	Process 04.02.01

Dependencies

SWCs

Module	Required Feature
IoHwAb	EcuIdnPin1
IoHwAb	EcuIdnPin2

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file

Required Global Data Outputs

Refer DataDict.m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
DualEcuIdnInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
DualEcuIdnPer1	None	100ms periodic

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
DualEcuIdn_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

7.2 - DualEcuIdn_MDD

Module Design Document

For

DualEcuIdn

Jan 10 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	Avinash James	1.0	10-Jan-2017

Table of Contents

1 Introduction 4

1.1 Purpose 4

2 McuDiagc & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of DualEcuIdn 6

3.2 Data Flow Diagram 6

3.2.1 Component level DFD 6

3.2.2 Function level DFD 6

4 Constant Data Dictionary 7

4.1 Program (fixed) Constants 7

4.1.1 Embedded Constants 7

5 Software Component Implementation 8

5.1 Sub-Module Functions 8

5.1.1 Init: DualEcuIdnInit1 8

5.1.1.1 Design Rationale 8

5.1.1.2 Module Outputs 8

5.1.2 Per: DualEcuIdnPer1 8

5.1.2.1 Design Rationale 8

5.1.2.2 Store Module Inputs to Local copies 8

5.1.2.3 (Processing of function)……… 8

5.1.2.4 Store Local copy of outputs into Module Outputs 8

Appendix A S 10

Appendix B Glossary 11

Appendix C References 13

Introduction

Purpose

Module design document for Dual Ecu Identification

McuDiagc & High-Level Description

Refer the Design.

Design details of software module

Graphical representation of DualEcuIdn

Data Flow Diagram

Component level DFD

N/A

Function level DFD

N/A

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
ECUIDNOTREAD_CNT_U08	1	Cnt	0U
Refer .m file

Software Component Implementation

Sub-Module Functions

The sub-module functions are grouped based on similar functionality that needs to be executed in a given “State” of the system (refer States and Modes). For a given module, the MDD will identify the type and number of sub-modules required. The sub-module types are described below.

Init: DualEcuIdnInit1

Design Rationale

Refer to FDD

Module Outputs

Refer to FDD

Per: DualEcuIdnPer1

Design Rationale

None

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD0

Store Local copy of outputs into Module Outputs

Refer to FDD

Refer to FDD

S

Abbreviation or Acronym	Description
DFD	Design functional diagram
MDD	Module design Document

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES011ADualEcuIdn	See Synergy subproject version

7.3 - DualEcuIdn_ReviewChecklist

Overview

Summary Sheet
Synergy Project
Source Code
PolySpace
Integration Manual

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES011A_DualEcuIdn_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. 1.2.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. Shawn Penning

Work CR ID:

EA4#9800

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

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

N/A

Davinci 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:

Shawn Penning

Review Date :

03/28/17

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

No

Other Reviewer(s):

Mateusz Bartocha

Hari Magidi

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

DualEcuIdn.c

Source File Revision:

3

Header File Name:

N/A

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

MDD Name:

DualEcuIdn_MDD

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

ES011A_DualEcuIdn_Design

Revision:

1.3.1

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

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

N/A

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

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

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsiged conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

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

Add Model Block Comments. Done 3/30/2017

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:

Shawn Penning

Review Date :

03/30/17

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Mateusz Bartocha

Hari Magidi

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

DualEcuIdn

Source File Revision:

3

Source File Name:

Source File Revision:

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

QAC version:

Windows User: eg 8.1.1-R N/A

QAC sub project version:

Windows User: eg. TL_100A_1.1.0 N/A

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Shawn Penning

Review Date :

03/30/17

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Mateusz Bartocha

Hari Magidi

Sheet 5: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Shawn Penning

Review Date :

03/28/17

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Mateusz Bartocha

Hari Magidi

8 - Component Implementation

Component Implementation

Component Documentation

8.1 - EcuTMeas_IntegrationManual

Integration Manual

For

EcuTMeas

VERSION: 3.0

DATE: 09-AUG-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-Mar-2015
2	ADC Hooks are added as input	KK	2.0	21-Mar-2016
3	Added config params	Shruthi Raghavan	3.0	09-AUG-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	FDD - ES210A ECU Temperature Measurement	(See project group sub-version in synergy)

Dependencies

SWCs

Module	Required Feature
None	N/A

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
ECUTMEAS_ECUTX_VOLT_U3P13 (/Nexteer/EcuTMeas/EcuTMeasConversionTables/EcuTx)	Give the values of the interpolation X table from project settings in order starting from the first element. Values should be single precision floating point type.	EcuTMeas
ECUTMEAS_ECUTY_DEGCGRD_S8P7 (/Nexteer/EcuTMeas/EcuTMeasConversionTables/EcuTy)	Give the values of the interpolation Y table from project settings in order starting from the first element. Values should be single precision floating point type.	EcuTMeas
ECUTMEAS_RNGDIAGCMAX_DEGCGRD_F32 (/Nexteer/EcuTMeas/EcuTMeasDiagc/MaxTLim)	Identifies the max temperature allowed to accumulate a diagnostic error	EcuTMeas
ECUTMEAS_RNGDIAGCMIN_DEGCGRD_F32 (/Nexteer/EcuTMeas/EcuTMeasDiagc/MinTLim)	Identifies the min temperature allowed to accumulate a diagnostic error	EcuTMeas
ECUTMEAS_NTC0X045FAILSTEP_CNT_U16 (/Nexteer/EcuTMeas/EcuTMeasDiagc/Ntc0x045FailStep)	Error Accumulator Test Step Size for Failed Ecu Temperature Test	EcuTMeas
ECUTMEAS_NTC0X045PASSSTEP_CNT_U16 (/Nexteer/EcuTMeas/EcuTMeasDiagc/Ntc0x045PassStep)	Error Accumulator Test Step Size for Pass Ecu Temperature Test	EcuTMeas
ECUTMEAS_DFTT_DEGCGRD_F32 (/Nexteer/EcuTMeas/EcuTMeasGeneral/DftTemp)	Default Temperature used under Fault Conditions	EcuTMeas
ECUTMEAS_FILTAU_HZ_F32 (/Nexteer/EcuTMeas/EcuTMeasGeneral/FilTau)	Sets the time constant for filtering the temperature measurement	EcuTMeas

*Also see descriptions in the DaVinci configurator

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

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
EcuTMeasInit1	On Init	RTE(Init)

Runnable	Scheduling Requirements	Trigger
EcuTMeasPer1	None	RTE(100ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

Non RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

8.2 - EcuTMeas_MDD

Module Design Document

For

EcuTMeas

26-Sep-2017

Prepared By:

Brendon Binder,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Sl.No	Description	Author	Version	Date
1	Initial Version	SB	1.0	23-Mar-2015
2	ADC Hooks are added as input	KK	2.0	21-Mar-2016
3	Added local constants for paramterbyte definitions	AJM	3.0	10-Apr-2017
4	Updated the graphical representation (all cal ports are removed), added local constants, design rationale, known limitations and unit tests considerations. Updated to the new template	Shruthi Raghavan	4.0	08-Aug-2017
5	Updated the DaVinci model (added new output).	Brendon Binder	5.0	26-Sep-2017

Table of Contents

1 Introduction 4

1.1 Purpose 4

2 EcuTMeas & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of EcuTMeas 6

3.2 Data Flow Diagram 6

3.2.1 Component level DFD 6

3.2.2 Function level DFD 6

4 Constant Data Dictionary 7

4.1 Program (fixed) Constants 7

4.1.1 Embedded Constants 7

5 Software Component Implementation 8

5.1 Sub-Module Functions 8

5.1.1 Init: EcuTMeasInit1 8

5.1.1.1 Design Rationale 8

5.1.2 Per: EcuTMeasPer1 8

5.1.2.1 Design Rationale 8

5.2 Server Runables 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 8

5.4.1 Local Function #1 8

5.4.1.1 Design Rationale 8

5.5 GLOBAL Function/Macro Definitions 8

5.5.1 GLOBAL Function #1 8

6 Known Limitations with Design 9

7 UNIT TEST CONSIDERATION 10

Appendix A Abbreviations and Acronyms 11

Appendix B Glossary 12

Appendix C References 13

Introduction

Purpose

Module design document for EcuTMeas

EcuTMeas & High-Level Description

Measures and diagnoses an analog based temperature sensor on ECU.

This particular design can tolerate a transfer function that is not necessarily linear but can be interpolated with 8 different XY pairs.

Design details of software module

Graphical representation of EcuTMeas

Data Flow Diagram

Component level DFD

Refer FDD simulink model

Function level DFD

Refer FDD simulink model

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value	Defined In
ECUTFILDMIN_DEGCGRD_F32	Single Precision Float	DegCgrd	-50.0F	EcuTMeas.c
ECUTFILDMAX_DEGCGRD_F32	Single Precision Float	DegCgrd	150.0F	EcuTMeas.c
NROFSNSRXYPT_CNT_U08	1	Cnt	8U*	EcuTMeas_Cfg_private.h
Refer DataDict.m file for other constants	-	-	-

*This the value might change based on EcuTx and EcuTy table size.

Software Component Implementation

Sub-Module Functions

Init: EcuTMeasInit1

Refer FDD simulink model

Design Rationale

‘Filter Initialization’ block in the FDD uses ‘FilLpInit’ library block twice rather than just once due to a design limitation with the Library block (see ‘Known limitations with design’). However, code has no such limitation. In code, the value to be written to the state variable according to the logic in ‘State Variable Initialization’ is calculated first. Then, the ‘FilLpInit’ library function is called just once and that will initialize the state variable with this calculated value and the gain according to the set frequency & time.

Per: EcuTMeasPer1

Refer FDD Simulink Model

Design Rationale

None

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	-	Type	Min	Max
Arguments Passed	N/A	-	-	-
Return Value	N/A	-	-	-

Design Rationale

N/A

GLOBAL Function/Macro Definitions

GLOBAL Function #1

Function Name	-	Type	Min	Max
Arguments Passed	N/A	-	-	-
Return Value	N/A	-	-	-

Known Limitations with Design

The FilLpInit block in the model cannot accept a variable as input for initialization of the state variable.

UNIT TEST CONSIDERATION

This component uses config params for some configurable constants. However for testing these in PIL/SIL, please use the following strategy:
1. Rename the EcuTMeas_Cfg_private_pil.h file in tools/local/include folder to EcuTMeas_Cfg_private.h
2. Replace the EcuTMeas_Cfg_private.h file in tools/local/generate folder with the above file.

Now, Tessy must be able to modify the values of these config params. We should then test them with the range that is given in their definition in the DataDict.m file

Abbreviations and Acronyms

Abbreviation or Acronym	Description
FDD	Functional Design Document. (See references)

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.4.0 R4.0 Rev 3
2	MDD Guideline	EA4 01.00.01
3	EA4 Software Naming Conventions.doc	01.01.00
4	Software Design and Coding Standards.doc	2.1
5	ES210A_EcuTMeas_Design (FDD)	Refer subproject verison on Synergy

8.3 - EcuTMeas_PeerReviewChecklist

Overview

Summary Sheet
Davinci Files
Source Code
PolySpace
Synergy Project

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES210A_EcuTMeas_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. ES210A_EcuTMeas_Impl_4.1.0

Change Owner:

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

Work CR ID:

EA4#16229

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci 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: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

N/A

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

N/A

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Brendon Binder

Review Date :

10/19/17

Component Type :

Application

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

EcuTMeas.c

Source File Revision:

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.

MDD Name:

EcuTMeas_MDD.docx

Revision:

5

FDD/SCIR/DSR/FDR/CM Name:

ES210A_EcuTMeas_Design

Revision:

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

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

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

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

Yes

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:

Brendon Binder

Review Date :

10/19/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

EcuTMeas.c

Source File Revision:

6

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Brendon Binder

Review Date :

10/19/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: 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:

Brendon Binder

Review Date :

10/19/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

9 - Component Implementation

Component Implementation

Component Documentation

9.1 - ElecGlbPrm Review

Overview

Summary Sheet
Synergy Project
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES999A_ElecGlbPrm_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. 6.5.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. Krishna Anne

Work CR ID:

EA4#12291

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

This version of the component is a .h and .c file with global constant definitions.

MDD not needed for this component. May be added if required for future revisions.QAC sub project is removed

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:

Krishna Anne

Review Date :

06/02/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

ElecGlbPrm.c

Source File Revision:

2

Header File Name:

ElecGlbPrm.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. 10

Header File Name:

ElecGlbPrm_Cfg.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. 3

MDD Name:

N/A

Revision:

FDD/SCIR/DSR/FDR/CM Name:

ES999A_ElecGlbPrm_Design

Revision:

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

Yes

Comments:

LGC used instead of LOGL. Design kept it this way

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

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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:

Stub file warnings are not cosnidered as they don’t end up in the integration project

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.

Yes

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:

Krishna Anne

Review Date :

06/02/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

ElecGlbPrm.c

Source File Revision:

2

Source File Name:

ElecGlbPrm.h

Source File Revision:

10

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.02.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

QAC version:

Windows User: eg 8.1.1-R

QAC sub project version:

Windows User: eg. TL_100A_1.1.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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

Bug finder shows warning 8.10. This is because the tool see no other file use the constant table, so not a real violation.

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Krishna Anne

Review Date :

06/02/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

9.2 - ElecGlbPrm_IntegrationManual

Integration Manual

For

ElecGlbPrm

VERSION: 1.0

DATE: 18-Jan-2017

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.	Description	Author	Version	Date
1	Initial version	Avinash James	1.0	18-Jan-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	FDD : ES999A_ElecGlbPrm_Design	See Synergy sub project version
2	Software Naming Conventions	Process 4.02.01
3	Software Design and Coding Standards	Process 4.02.01

Dependencies

SWCs

Module	Required Feature
None

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

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

ElecGlbPrm_Cfg.h

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
/Nexteer/ElecGlbPrm/ ElecGlbPrmCfg	Electrical global parameters which are configurable

Note:

Refer the CM010 RH850 Mcu Config for configuration of Electrical global config paramters

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

None

Required Global Data Outputs

None

Specific Include Path present

Yes.

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger

Runnable	Scheduling Requirements	Trigger

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None.

Appendix

10 - Component Implementation

Component Implementation

Component Documentation

10.1 - GateDrv0Ctrl_IntegrationManual

Integration Manual

For

Gate Drive 0 Control

VERSION: 3

DATE: 11-Sep-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

Version	Description	Author	Date
1	Initial version	Rijvi Ahmed	08-July-2016
2	Updated for SPI MCAL update in FDD v2.2.0	Shruthi Raghavan	15-Mar-2017
3	Details of new config parameter added.	Shruthi Raghavan	11-Sep-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

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	Software Naming Conventions	Process 04.04.02
2	Software Coding Standards	Process 04.04.02
3	FDD – ES311A GateDrv0Ctrl	See synergy sub project version

Dependencies

SWCs

Module	Required Feature
Spi_Renesas_Ar4.0.3_01.06.05_HF

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter

Notes

SWC

/Nexteer/GateDrv0Ctrl/GateDrv0CtrlGenCfg/

GateDrv0FetFltMtgtnEna

GATEDRV0FETFLTMTGTNENA_ULS_LOGL:

Field effect transistor fault mitigation enable.

If TRUE, the gate drive component will notify the system when a FET fault is detected.

GateDrv0Ctrl

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

See FDD DataDict.m.

Required Global Data Outputs

See FDD DataDict.m.

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
GateDrv0CtrlInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
GateDrv0CtrlPer1	At the beginning of all 2ms Tasks as close as possible	RTE (2 ms)
GateDrv0CtrlPer2	At the end of all 2ms Tasks as close as possible	RTE (2 ms)

Memory Map REQUIREMENTS

Mapping

Memory Section *	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Non RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in configurator

RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

10.2 - GateDrv0Ctrl_MDD

Module Design Document

For

Gate Drive 0 Control

VERSION: 9

DATE: 12-Jan-2018

Prepared By:

Shawn Penning,

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

Version	Description	Author	Date
1	Initial version	Rijvi Ahmed	07-July-2016
2	Updated to design revision 1.8.0	Avinash James	21-Jan-2017
3	Updated to design revision 2.0.0	Shruthi Raghavan	17-Feb-2017
4	Updated to design revision 2.1.0	Shruthi Raghavan	27-Feb-2017
5	Updated to design revision 2.3.0	Shruthi Raghavan	14-Mar-2017
6	Updated to design revision 2.4.0 – Fix for phase reasonableness issues found during integration	Shruthi Raghavan	24-Mar-2017
7	Removed unused inputs from OperFltMonSt function. Added UT considerations per anomaly EA4#11845	Shruthi Raghavan	26-May-2017
8	Updated graphical representation for the new outputs and client call. Added details for changed & new local functions Added new enum type and local constant	Shruthi Raghavan	11-Sep-2017
9	Updated design rationale for the state machine in Configuration State of gate drive. Added UT considerations per test corrections required in anomaly corrective action.	Shawn Penning	12-Jan-2018

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 GATEDRV0CTRL & High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation of GATEDRV0CTRL 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.2 Initialization Functions 11

7.2.1 Per: GateDrv0CtrlInit1 11

7.3 PERIODIC FUNCTIONS 11

7.3.1 Per: GateDrv0CtrlPer1 11

7.3.1.1 Design Rationale 11

7.3.1.2 Processing of Function 11

7.3.2 Per: GateDrv0CtrlPer2 11

7.3.2.1 Design Rationale 11

7.3.2.2 Processing of Function 11

7.4 Interrupt Functions 11

7.5 Serial Communication Functions 11

7.6 Local Function/Macro Definitions 12

7.6.1 Local Function #1 12

7.6.1.1 Description 12

7.6.2 Local Function #2 12

7.6.2.1 Description 12

7.6.3 Local Function #3 12

7.6.3.1 Description 12

7.6.4 Local Function #4 12

7.6.4.1 Description 12

7.6.5 Local Function #5 12

7.6.5.1 Description 13

7.6.6 Local Function #6 13

7.6.6.1 Description 13

7.6.7 Local Function #7 13

7.6.7.1 Description 13

7.6.8 Local Function #8 13

7.6.8.1 Description 13

7.6.9 Local Function #9 13

7.6.9.1 Description 14

7.6.10 Local Function #10 14

7.6.10.1 Description 14

7.6.11 Local Function #11 14

7.6.11.1 Description 14

7.7 GLObAL Function/Macro Definitions 14

8 Known Limitations With Design 15

9 UNIT TEST CONSIDERATION 16

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	1.02
2	Software Naming Conventions	1.02
3	Software Coding Standards	1.01
4	FDD – ES311A_GateDrv0Ctrl_Design	See synergy sub project version

GATEDRV0CTRL & High-Level Description

This module configures the GateDrive0 connected with SPI channel CSIH2. It also does the diagnostics for GateDrive0 using SPI interface.

It also performs phase reasonable diagnostics when the inverter 0 fault input is active. Detects FET fault and indicates the type of fault and also in the case of single fet fault it indicates the phase faulted as well. Phase reasonableness is disabled on a phase with shorted FET

Design details of software module

Graphical representation of GATEDRV0CTRL

Variable Data Dictionary

User defined typedef definition/declaration

Typedef Name

Element Name

User Defined Type

Legal Range

(min)

Legal Range

(max)

GateDrvCfgSt

-

Enumeration

0

4

Variable definition for enumerated types

Enum Name	Element Name	Value
GateDrvCfgSt	GATEDRVCFGST_RSTGATEDRVST	0
	GATEDRVCFGST_WAIT2MS	1
	GATEDRVCFGST_CFGREG	2
	GATEDRVCFGST_SETUPSPIREGREAD	3
	GATEDRVCFGST_READBACKREGS	4

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value
GATEDRVOFFSTCHKSIZE_CNT_U08	1U	Cnt	((TblSize_m(ELECGLBPRM_GATEDRVOFFSTCHKDATA_CNT_U16)/8U) - 1U)
BITMASK0_CNT_U08	1	Cnt	0x01U
BITMASK2_CNT_U08	1	Cnt	0x04U
BITMASK4_CNT_U08	1	Cnt	0x10U
MOTDRVERRMIN_NANOSEC_F32	Single precision float	NanoSec	0.0F
MOTDRVERRMAX_NANOSEC_F32	Single precision float	NanoSec	40000000.0F
DIAG2REGBOOTSTRPSPLYFLTSTRTPOS_CNT_U08	1	Cnt	5U

Global

Constant Name

Refer to the FDD

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
Refer to the design

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

Per: GateDrv0CtrlInit1

PERIODIC FUNCTIONS

Per: GateDrv0CtrlPer1

Design Rationale

None

Processing of Function

See design model for details.

Per: GateDrv0CtrlPer2

Design Rationale

It is the intent of this design to hold the value of

MotDrvr0IninTestCmpl between iterations of GateDrv0CtrlPer2.

There was an inexplicable model issue in which MotDrvr0IninTestCmpl

was being reset to 0 when MotDrvr0IninTestCmpl was not being

written in the IF branch of model (refer model notes)

Implementation Considerations:

No need to use a PIM or a static variable as this signal is an RTE

output. Since RTE signals work like a static variable, the

implementation always holds the last value.

Processing of Function

See design model for details.

Interrupt Functions

None

Serial Communication Functions

None

Local Function/Macro Definitions

Local Function #1

Function Name	SpiAsyncTx	Type	Min	Max
Arguments Passed	Channel_Cnt_T_u08	Spi_ChannelType	0	Full
	TxData_Cnt_T_u16	Spi_DataType	0	Full
	Sequence_Cnt_T_u08	Spi_SequenceType	0	Full
Return Value	None

Description

(void) Spi_WriteIB( Channel_Cnt_T_u08, &TxData_Cnt_T_u16 );

(void) Call_Spi_AsyncTransmit( Sequence_Cnt_T_u08 );

Local Function #2

Function Name	OffStVrfySt	Type	Min	Max
Arguments Passed	None
Return Value	None

Description

See GateDrv0Ctrl/GateDrv0CtrlPer2/Gate Drive Enable/Gate Drive State/OffState Verification Stateblock in design model.

Local Function #3

Function Name	OffStVrfyData	Type	Min	Max
Arguments Passed	None
Return Value	Flt_Cnt_T_logl	Boolean	FALSE	TRUE

Description

See GateDrv0Ctrl/GateDrv0CtrlPer2/Gate Drive Enable/Gate Drive State/OffState Verification State/OffSt Verification Chk and Transition to Config State/OffStChk Incomplete/Offstate Verification /OffState Verification Check block in design model.

*It is optimized in the implementation to reduce the high static path count.

Local Function #4

Function Name	CfgSt	Type	Min	Max
Arguments Passed	None
Return Value	None

Description

See GateDrv0Ctrl/GateDrv0CtrlPer2/Gate Drive Enable/Gate Drive State/Configuration State block in design model.

The state machine is implemented slightly differently in code vs the model, but they are functionally equivalent.
The model adds 1 to the GateDrv0CfgCnt Pim to change to the next state in Configuration,but the code assigns values from a local enumeration (see section 5.2) instead of performing arithmetic on the Pim. The enumerated state assigned to GateDrv0CfgCnt Pim will match with the resulting state in the model.

Local Function #5

Function Name	ReadBackRegs	Type	Min	Max
Arguments Passed	None
Return Value	None

Description

See GateDrv0Ctrl/GateDrv0CtrlPer2/Gate Drive Enable/Gate Drive State/Configuration State/Read back Registers block in design model.

Local Function #6

Function Name	OperFltMonrSt	Type	Min	Max
Arguments Passed	PhaOnTiMeasdA_NanoSec_T_u32	Uint32	0	4294967295
	PhaOnTiMeasdB_NanoSec_T_u32	Uint32	0	4294967295
	PhaOnTiMeasdC_NanoSec_T_u32	Uint32	0	4294967295
	PhaOnTiSumAExp_NanoSec_T_u32	Uint32	0	4294967295
	PhaOnTiSumBExp_NanoSec_T_u32	Uint32	0	4294967295
	PhaOnTiSumCExp_NanoSec_T_u32	Uint32	0	4294967295
	*MotDrvErrA_NanoSec_T_f32	Single precision float	0.0F	40000000.0F
	*MotDrvErrB_NanoSec_T_f32	Single precision float	0.0F	40000000.0F
	*MotDrvErrC_NanoSec_T_f32	Single precision float	0.0F	40000000.0F
Return Value	None

Description

See GateDrv0Ctrl/GateDrv0CtrlPer2/Gate Drive Enable/Gate Drive State/Operate Fault Monitor State block in design model.

Local Function #7

Function Name	GateDrvDetermineOnStSngFETFlt	Type	Min	Max
Arguments Passed	*SpclSnpshtData0_Cnt_T_u32	Uint32	0U	4294967295U
	*SpclSnpshtData1_Cnt_T_u32	Uint32	0U	4294967295U
	*SpclSnpshtData2_Cnt_T_u32	Uint32	0U	4294967295U
Return Value	GenGateDrvFlt_Cnt_T_logl	Boolean	FALSE	TRUE

Description

See GateDrv0Ctrl/GateDrv0CtrlPer2/Gate Drive Enable/Gate Drive State/Operate Fault Monitor State/Determine Faults/Status Register indicates Fault/Determine OnState Single FET Fault block in design model.

Local Function #8

Function Name	GateDrvDetermineVltgFlt	Type	Min	Max
Arguments Passed	*SpclSnpshtData0_Cnt_T_u32	Uint32	0U	4294967295U
	*SpclSnpshtData1_Cnt_T_u32	Uint32	0U	4294967295U
	*SpclSnpshtData2_Cnt_T_u32	Uint32	0U	4294967295U
Return Value	GenGateDrvFlt_Cnt_T_logl	Boolean	FALSE	TRUE

Description

See GateDrv0Ctrl/GateDrv0CtrlPer2/Gate Drive Enable/Gate Drive State/Operate Fault Monitor State/Determine Faults/Status Register indicates Fault/Determine VREG/Bootstrap Voltage Fault block in design model.

Local Function #9

Function Name	GateDrvDetermineGenericFlt	Type	Min	Max
Arguments Passed	GateDrvAllSts_Cnt_T_u16	Uint16	0	0xFFFF
	*SpclSnpshtData0_Cnt_T_u32	Uint32	0U	4294967295U
	*SpclSnpshtData1_Cnt_T_u32	Uint32	0U	4294967295U
	*SpclSnpshtData2_Cnt_T_u32	Uint32	0U	4294967295U
Return Value	GenGateDrvFlt_Cnt_T_logl	Boolean	FALSE	TRUE

Description

See GateDrv0Ctrl/GateDrv0CtrlPer2/Gate Drive Enable/Gate Drive State/Operate Fault Monitor State/Determine Faults/Status Register indicates Fault/Determine Generic Gate Drive Fault block in design model.

Local Function #10

Function Name	SetNtcStInfo	Type	Min	Max
Arguments Passed	PhaOnTiMeasd_NanoSec_T_u32	Uint32	0	4294967295
	PhaOnTiSumExp_NanoSec_T_u32	Uint32	0	4294967295
	AbsltErr_NanoSec_T_f32	Single precision float	0	3.4E+38
	BitMask_Cnt_u08	Uint8	0	127
	NtcStInfo_Uls_T_u08	Uint8	0	255
Return Value	Flt_Uls_T_lgc	Boolean	False	True

Description

See ES311A_GateDrv0Ctrl/GateDrv0Ctrl/GateDrv0CtrlPer2/GateDrv Enable/Disable/Gate Drive Enable/Gate Drive State/Operate Fault Monitor State/Determine Faults/No Faults/GateDrvPhaReasbnChk/MeasdPhaFltChkABC block in design model. This function implements NtcStInfoPhaA, NtcStInfoPhaB and NtcStInfoPhaC common functionality.

Local Function #11

Function Name	ChkResVrfyRegs	Type	Min	Max
Arguments Passed	PrmByte_Cnt_T_u08	Uint8	128	138
Return Value	None	-	-	-

Description

Check Results of Verify GateDrive0 Registers based on calculated parameter byte and take appropriate action

Local Function #12

Function Name	WriteOutput	Type	Min	Max
Arguments Passed	None	-	-	-
Return Value	None	-	-	-

Description

Implements the ‘ES311A_GateDrv0Ctrl_new/GateDrv0Ctrl/GateDrv0CtrlPer2/Write Output’ block in simulink model.

GLObAL Function/Macro Definitions

None

Known Limitations With Design

Note: The PIM Ivtr0InactvSts is written in Per2 and used in Per1 as well as Per2. Data consistency is not an issue because of explicit scheduling requirements given in the integration manual.

Note:

At multiple places, the implementation does not reset the error counter PIM when rollover to zero happens but the model does. This is because in the code the rollover is automatic (and marked intentional ), whereas in the model it isn’t that way and requires a manual reset.
In all the cases where (1) is applicable, the model comments say 65535 rather than 4294967295 as the value at which reset should occur. Upon discussion with FDD owner, the comment is wrong and will be changed with the next update.

UNIT TEST CONSIDERATION

Overflow is intentional and acceptable on PhaOnTiSumAExp_NanoSec_T_u32, PhaOnTiSumBExp_NanoSec_T_u32 and PhaOnTiSumCExp_NanoSec_T_u32 in Per2 function.
Rollover is intentional on Rte_Pim_GateDrv0SpiTrsmErrCntr. The code has comments that also mention this consideration.
Note: While the code and model do not exactly match on the implementation (because the model manually resets this error counter, while the code lets it auto-reset due to rollover), the output should be the same for the PIM because functionally they are same.
The model is designed such that the table ELECGLBPRM_GATEDRVOFFSTCHKDATA_CNT_U16 is never indexed with a value of greater than its size in real life. However, in code we need an explicit check for safety. For this reason, when Rte_Pim_GateDrv0OffStChkIdx is given a value greater than or equal to the size of this table, the model and code will behave differently (this is expected , because it is an impossible scenario in the real world).
->
For PIL testing, the consideration is that the input values given to Rte_Pim_GateDrv0OffStChkIdx when MIL vectors are not available should be less than or equal to (GATEDRVOFFSTCHKSIZE_CNT_U08).
This component has a config parameter. Use the file from local/include folder and NOT the one from local/generate folder for testing so that Tessy can vary the value of the configuration parameter in the range that it is given in the data dictionary.
Please rectify wrong expected values of tests as part of anomaly corrective action. See PDF attached here (refer to both root cause and corrective action).

10.3 - GateDrv0Ctrl_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace
help
Version History

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

GateDrv0Ctrl

Revision / Baseline:

ES311A_GateDrv0Ctrl_Impl_3.2.0

Change Owner:

Shruthi Raghavan

Work CR ID:

EA4#20591, EA4#20770

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.

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

N/A

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

0.5

0.75

0.5

Component developer reviewers:

0

0.75

0.5

3

Other reviewers:

0

1

0.5

Total hours

0.5

2.5

1.5

4.5

Content reviewed

Lines of code:

4

Elements of .arxml content:

3

Pages of documentation:

0

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. Save in the doc folder of the component implementation, with the file name in the format SWCShortName_Review.xlsx. If the existing review in Synergy has a different name, the name must be changed IN SYNERGY (rather than by syncing in a new file with the new name) so that the file history will be properly maintained.

Before the peer review, the change owner shall: (NOTE - time for completing these items is to be counted as the Change Owner Review Prep Time)
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.01

21-Feb-18

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:

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

Yes

Comments:

File/folder structure is correct per documentation in

Yes

Comments:

TL109A_SwcSuprt

General Notes / Comments:

Add TL105 subproject : Done 2/28/2018

Review Board:

Change Owner:

Shruthi Raghavan

Review Date :

02/28/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Steven Horwath

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

Sheet 3: Davinci Files

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

N/A

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

N/A

Comments:

Do all port interface names end in PortIf and a sequence

N/A

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

Yes

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

file) in all areas where arxml was changed and/or the

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

N/A

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

N/A

Comments:

(name, data type)

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

removed

All sender/receiver port read/writes using "Write (explicit)"

N/A

Comments:

and "Read (explicit by argument)"(List justification if not)

Runnable calling frequencies match DataDict.m file

N/A

Comments:

Runnable port access matches the DataDict.m file

N/A

Comments:

DataDict.m display variables: created as

Yes

Comments:

PerInstanceMemory. Name and data type match DataDict.m file.

Per Instance Memory names and data types

N/A

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

N/A

Comments:

No change

General Notes / Comments:

Review Board:

Change Owner:

Shruthi Raghavan

Review Date :

02/28/18

Component Type :

Application

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Hari Mattupalli

Comments:

Other Reviewer(s):

Gerald Mccann

Steven Horwath

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

Sheet 4: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

GateDrv0Ctrl.c

Source File Revision:

12

Header File Name:

GateDrv0Ctrl_Cfg_private.h.tt

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) 1 (template Rev)

MDD Name:

GateDrv0Ctrl_MDD.doc

Revision:

9

SWC Design Name:

ES311A_GateDrv0Ctrl_Design

Revision:

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

Yes

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

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

Yes

Comments:

or Model) in all areas where code was changed and/or

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

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

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

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

N/A

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

N/A

Comments:

Design subfunctions and/or model blocks identified

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

No

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

Display variable units do not affect software

General Notes / Comments:

Review Board:

Change Owner:

Shruthi Raghavan

Review Date :

02/28/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Gerald Mccann

Comments:

Integrator and or
SW lead:

Hari Mattupalli

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

Steven Horwath

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

Steven Horwath

Sheet 5: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

GateDrv0Ctrl.c

Source File Revision:

12

EA4 Static Analysis Compliance Guideline version:

1.04

Poly Space version:

2013b

TL109A sub project version:

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

generated content only changes

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

changed 13.7 comment

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

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

Yes

Comments:

with conditional compilation, has Polyspace been run with all

Archived results are with config param set to TRUE

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

(Note which conditional compilation results have been archived)

Codemetrics count OK

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Run the Polyspace with config param set to FALSE. : Ran Polyspace with config param as variable in [0,1] range :Done 3/1/2018

Deviation Comment for 13.7 has default explanation - change to the explanation relevant to ES311A : Done 2/27/2018

13.7 MISRA violation is reviewed and is OK. Static analysis is run with the config param set up as a variable to verify that the 13.7 violation did not occur.

Data Flow orange checks and MISRA Rule 9.1 deviations are caused by Polyspace unable to get the range of values returned by address from client calls.

Overflow warnings are in filter library because Polyspace considers full range for library function arguments. Its not a ES311A code issue

Pim GateDrv0OffStChkIdx range is [0,255] in the m file but is checked to be <= (size-1) of ELECGLBPRM_GATEDRVOFFSTCHKDATA_CNT_U16 in OffStVrfySt function. So the out of bounds array access issue reported by Polyspace will never actually occur

Cyclomatic complexity of 17 is because of the SinCos_f32 function. This code has max cyclomatic complexity of 14 only.

Review Board:

Change Owner:

Shruthi Raghavan

Review Date :

03/01/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Steven Horwath

Anu K

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

Sheet 6: help

Summary sheet:

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

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

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

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

Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed.

Source code:

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.

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)

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)

Intended Use: For SWC Designs, list the Synergy baseline number (just the number part of the Synergy baseline name) of the SWC Design baseline being implemented. E.g., for SF001A_Assi_Design_1.3.1, this field would say "1.3.1"

Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).

Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored).

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

Davinci Files

Intended Use: Identify if previous version was compared and only the expected change(s) was present. This is for text files only, not binary or GUIs

Polyspace

eg. 2013b

Integration manual

Intended Use: Identify which file is being reviewed

Intended Use: Identify which version of the integration manual has been reviewed.

Synergy

Refer to EA4 Common Naming Conventions document, section “Synergy Baseline Names for core components”

The following subprojects should be included for all component implementations:
• AR200A_ArSuprt_Impl
• AR201A_ArCplrSuprt_Impl
• TL101A_CptRteGen
• TL103A_CplrSuprt
• TL109A_SwcSuprt
• Corresponding _Design project used for the implementation

The following subprojects should be included as needed by each component:
• AR10xx_Nxtr*_Impl library components as needed by each component
• AR202x_MicroCtrlrSuprt_Impl as needed (for register header files for components making direct register access)[add notes about when to add a stub header file]
• Xx999x_xxxxGlbPrm_Impl as needed by each component
• TL105A_Artt for components with generated content

The following should NOT be included as subprojects:
• TL107x_DavinciSuprt (aka StdDef)
• TL100A_QACSuprt (QAC subproject was previously included but should be removed going forward)
• Any other component (not mentioned anywhere above) whose .h file is needed. For these components, a “stub” .h file should be created, containing only the multiple include protection and the definitions and function prototypes actually needed by the component with the #include, and placed in the “including” component’s local\include folder.

misc in Summary sheet

(integrator, designer, unit test coordinator, etc.)

For a new component, use number of lines in all source files reviewed, including files in the src and include folders and any generated cfg.h and cfg.c files. For a changed component, try to add up how many lines, including comments and blank lines, were in the changed areas that were reviewed. Not just the actual changed lines, but the number of lines in the blocks of code you had to look at to review the change.

add up the number of ports, number of PIM variables, number if IRVs, number of runnables, number of NVM blocks in the component (all of them for review of a new component, the new and modified ones for review of a change)

add the number of pages in the MDD and integration manual for a new component; for a modified component, count the number of pages that contained a change.

Reviewer

Required attendance for this type of change

Review spreadsheet tab(s)

Component group peer

All

Component owner and/or SWC Design author

*Initial creation of any new component
*Simulink model changes (any change to the model other than just updating the change log)

Source

Integrator and/or SW lead of first program planning to use the component

*Initial creation of any new component
*new or changed NVM blocks, NVM datatypes, or NVM usage (added or removed or changed NVM API calls in any runnable)
*Major rev (X changed in the X.Y.X design baseline number; means there was a component interface change)
*new or changed config params
*all MM component changes

Davinci files, Integration manual, source for NVM changes and for all MM component changes.

Unit test coordinator

Fixes for coverage issues

Source

SQA

None

For each reviewer category listed on each tab, there should either be
• the name of the reviewer who attended
or
• a comment indicating
o why that reviewer was not required for this change
or
o who approved holding the review without that required reviewer (approval must
be from the software manager or a software supervisor)

Sheet 7: 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
2.01	Added a help tab and appropriate links Added field on Summary sheet to report hours spent and content reviewed Changed wording in an item in Polyspace tab and Source code tab	SW Engineering team	21-Feb-18	Lonnie Newton, Steven Horwath, Kevin Smith, Lucas Wendling, Vinod Shankar	21-Feb-18	Released

11 - Component Implementation

Component Implementation

Component Documentation

11.1 - HwAgArbn_DesignReview

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES238B_HwAgArbn_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. 1.0.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. Matthew Leser

Work CR ID:

EA4#7058

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci 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:

Matthew Leser

Review Date :

11/30/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

N/A

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

Yes

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

11/30/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

HwAgArbn.c

Source File Revision:

1

Header File Name:

N/A

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

MDD Name:

HwAgArbn_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

ES238B_HwAgArbn_Design

Revision:

1

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

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.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsiged conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

N/A

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

Yes

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:

Matthew Leser

Review Date :

11/30/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

HwAgArbn_MDD.docx

MDD Revision:

1

Source File Name:

HwAgArbn.c

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

N/A

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

11/30/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

HwAgArbn.c

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

Draft 1.2

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 TL108a_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 N/A

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Matthew Leser

Review Date :

11/30/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

11/30/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

11.2 - HwAgArbn_IntegrationManual

Integration Manual

For

HwAgArbn

VERSION: 1.0

DATE: 7-Nov-2016

Prepared By:

Matthew Leser,

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	Matthew Leser	1.0	7-Nov-2016

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 Dependencies 7

3.1 SWCs 7

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

4 Configuration REQUIREMeNTS 8

4.1 Build Time Config 8

4.2 Configuration Files to be provided by Integration Project 8

4.3 Da Vinci Parameter Configuration Changes 8

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
	<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.	Title	Version
<1>	<MDD Guidelines>	Process 04.02.00
<2>	<Software Naming Conventions>	Process 04.02.00
<3>	<Coding standards>	2.1
<4>	FDD – ES238B_HwAgArbn_Design	See Synergy Subproject version

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
N/A

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

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
None

Runnable	Scheduling Requirements	Trigger
HwAgArbnPer1	None	RTE(4ms)

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

11.3 - HwAgArbn_MDD

Module Design Document

For

HwAgArbn

Version: 1.0

Date: 7-Nov-2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Matthew Leser,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Matthew Leser	1.0	7-Nov-2016

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 HwAgArbn & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of HwAgArbn 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: <Component Name>_Init<n> 9

5.1.2 Per: HwAgArbnPer1 9

5.2 Server Runables 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 10

7 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 14

Introduction

Purpose

Scope

HwAgArbn & High-Level Description

Refer FDD

Design details of software module

Refer FDD

Graphical representation of HwAgArbn

Data Flow Diagram

Refer FDD

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
CORRLNSTSMASKSIGA_CNT_U08	1	Cnt	0x01
MAXSTALLCNTR_CNT_U08	1	Cnt	255U
HWAGLIM_HWDEG_F32	1	HwDeg	900.0F

Software Component Implementation

Refer FDD

Sub-Module Functions

Init: <Component Name>_Init<n>

None

Per: HwAgArbnPer1

Refer FDD

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	CorrSigAvlChkRev1	Type	Min	Max
Arguments Passed	SigRollgCnt_Cnt_T_u08	uint8	0	255
	SigQlfr_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	* LstRollgCnt_Cnt_T_u08	uint8	0	255
	* StallCnt_Cnt_T_u08	uint8	0	255
Return Value	SigAvl_Cnt_T_lgc	boolean	FALSE	TRUE

Design Rationale

None

Processing

Refer FDD CorrSigAvlChkRev1 State flow Chart

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	Process 04.02.00
3	Software Naming Conventions.doc	Process 04.02.00
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES238B_HwAgArbn_Design	See Synergy SubProject version

12 - Component Implementation

Component Implementation

Component Documentation

12.1 - HwAgCorrln_DesignReview

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES239B_HwAgCorrln_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. 2.0.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. Jayakrishnan T

Work CR ID:

EA4#10437

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci 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:

Jayakrishnan T

Review Date :

03/30/17

Lead Peer Reviewer:

Matthew Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Jayakrishnan T

Review Date :

03/30/17

Component Type :

Application

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

HwAgCorrln.c

Source File Revision:

2

Header File Name:

N/A

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

MDD Name:

HwAgCorrln_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES239B_HwAgCorrln_Design

Revision:

2.0.1

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

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

N/A

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

N/A

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsiged conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

N/A

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

Yes

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:

Jayakrishnan T

Review Date :

03/30/17

Lead Peer Reviewer:

Matthew Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

HwAgCorrln_MDD.docx

MDD Revision:

2

Source File Name:

HwAgCorrln.c

Source File Revision:

2

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Jayakrishnan T

Review Date :

03/30/17

Lead Peer Reviewer:

Matthew Lesser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

HwAgCorrln.c

Source File Revision:

2

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

Draft 1.2

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 TL108a_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 N/A

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Jayakrishnan T

Review Date :

03/30/17

Lead Peer Reviewer:

Matthew Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Jayakrishnan T

Review Date :

03/30/17

Lead Peer Reviewer:

Matthew Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

12.2 - HwAgCorrln_IntegrationManual

Integration Manual

For

HwAgCorrln

VERSION: 2.0

DATE: 30-MAR-2017

Prepared By:

Jayakrishnan T,

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	Matthew Leser	1.0	30-Nov-2016
2	Updated to FDD v2.0.1	Jayakrishnan T	2.0	30-Mar-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	FDD – ES239B_HwAgCorrln_Design	See Synergy sub project version
2	Software Naming Conventions	Process 4.01.00
3	Software Design and Coding Standards	Process 4.01.00

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
FLTINJENA	Set to ‘STD_ON’ for fault injection

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file in the FDD

Required Global Data Outputs

Refer DataDict.m file file in the FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
HwAgCorrlnInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
HwAgCorrlnPer1	None	RTE (4 ms)

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None.

Appendix

None

12.3 - HwAgCorrln_MDD

Module Design Document

For

HwAgCorrln

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Matthew Leser

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Matthew Leser	1.0	7-Nov-2016
Updated to FDD v2.0.1	Jayakrishnan T	2.0	30-Mar-2017

Table of Contents

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 HwAgCorrln High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of ‘HwAgCorrln’ 6

3.2 Data Flow Diagram 6

3.2.1 Component level DFD 6

3.2.2 Function level DFD 6

4 Constant Data Dictionary 7

4.1 Program (fixed) Constants 7

4.1.1 Embedded Constants 7

5 Software Component Implementation 8

5.1.1 Sub-Module Functions 8

5.1.2 Interrupt Service Routines 8

5.1.3 Server Runnable Functions 8

5.1.4 Module Internal (Local) Functions 8

5.1.5 Transition Functions 8

6 Known Limitations with Design 9

7 UNIT TEST CONSIDERATION 10

Appendix A Abbreviations and Acronyms 11

Appendix B Glossary 12

Appendix C References 13

Introduction

Purpose

Scope

HwAgCorrln High-Level Description

Refer FDD

Design details of software module

Graphical representation of ‘HwAgCorrln’

Data Flow Diagram

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Refer .m file

Local Constants

Constant Name	Resolution	Units	Value
CORRLNSTSMINVAL_CNT_U08	1	CNT	0U
CORRLNSTSMAXVAL_CNT_U08	1	CNT	1U
NRVLDSIGMIN_CNT_U08	1	CNT	0U
NRVLDSIGMAX_CNT_U08	1	CNT	2U
MAXSTALLCNTR_CNT_U08	1	CNT	255U

Software Component Implementation

Sub-Module Functions

Initialization sub-module {_Init()}

None

Periodic sub-module {_Per()}

HwAgCorrlnPer1 (Refer FDD for details)

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	HwAgSigAvlChk	Type	Min		Max
Arguments Passed	SigRollg_Cnt_T_u08	uint8	0	255
	SigQlfr_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	*LstRollgCnt_Cnt_T_u08	uint8	0	255
	*LstStallCnt_Cnt_T_u08	uint8	0	255
Return Value	SigAvl_Cnt_T_lgc	boolean	FALSE	TRUE

Description

Transition Functions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	Software Naming Conventions.doc	2.0
4	Software Design and Coding Standards.doc	2.1
5	FDD - ES239B_HwAgCorrln_Design	See Synergy sub project version

13 - Component Implementation

Component Implementation

Component Documentation

13.1 - HwTq10Meas_IntegrationManual

Integration Manual

For

HwTq10Meas

VERSION: 1.0

DATE: 12-Jan-2018

Prepared By:

Software Engineering,

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Description	Author	Version	Date
Initial version	Pratik Jadhav	1.0	12-Jan-2018

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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	FDD – ES225A_HwTq10Meas_Design	See Synergy sub project version
2	Software Naming Conventions	01.01.00
3	Software Design and Coding Standards	2.1

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

Parameter	Notes	SWC
None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file in the FDD

Required Global Data Outputs

Refer DataDict.m file file in the FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
HwTq10MeasInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
HwTq10MeasPer1	None	RTE (2 ms)
HwTq10MeasPer2	None	RTE (100 ms)
HwTq10MeasHwTq10AutTrim_Oper	None	Server invocation
HwTq10MeasHwTq10ClrTrim_Oper	None	Server invocation
HwTq10MeasHwTq10ReadTrim_Oper	None	Server invocation
HwTq10MeasHwTq10TrimPrfmdSts_Oper	None	Server invocation
HwTq10MeasHwTq10WrTrim_Oper	None	Server invocation

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
HwTq10Meas_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

RTE NvM Blocks

Block Name

HwTq10Offs

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None.

Appendix

None

13.2 - HwTq10Meas_MDD

Module Design Document

For

HwTq10Meas

12-Jan-2018

Prepared By:

Software Engineering,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	Pratik Jadhav	1.0	12-Jan-2018

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 HwTq10Meas High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of HwTq10Meas 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: HwTq10MeasInit1 9

5.1.1.1 Design Rationale 9

5.1.2 Per: HwTq10MeasPer1 9

5.1.2.1 Design Rationale 9

5.1.3 Per: HwTq10MeasPer2 9

5.1.3.1 Design Rationale 9

5.2 Server Runnables 10

5.2.1 HwTq10MeasHwTq10AutTrim 10

5.2.1.1 Design Rationale 10

5.2.2 HwTq10MeasHwTq10ClrTrim 10

5.2.2.1 Design Rationale 10

5.2.3 HwTq10MeasHwTq10ReadTrim 10

5.2.3.1 Design Rationale 10

5.2.4 HwTq10MeasHwTq10TrimPrfmdSts 10

5.2.4.1 Design Rationale 10

5.2.5 HwTq10MeasHwTq10WrTrim 10

5.2.5.1 Design Rationale 10

5.3 Interrupt Functions 10

5.4 Module Internal (Local) Functions 11

5.4.1 Local Function #1 11

5.4.1.1 Design Rationale 11

5.4.2 Local Function #2 11

5.4.2.1 Design Rationale 11

5.4.3 Local Function #3 11

5.4.3.1 Design Rationale 11

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Appendix A Abbreviations and Acronyms 14

Appendix B Glossary 15

Appendix C References 16

Introduction

Purpose

Refer to FDD.

Scope

HwTq10Meas High-Level Description

Refer to FDD

Design details of software module

Graphical representation of HwTq10Meas

Data Flow Diagram

Component level DFD

Refer to FDD

Function level DFD

Refer to FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
CRCTBLSIZE_CNT_U08	1	Cnt	16U

* Refer to FDD for other constant definitions

Software Component Implementation

Sub-Module Functions

Init: HwTq10MeasInit1

Design Rationale

None

Per: HwTq10MeasPer1

Design Rationale

Clear local buffer in the below path of the model has not been implemented, because it’s not required.

Path : ES225A_HwTq10Meas/HwTq10Meas/HwTq10MeasPer1/Raw Data Processing/Clear Local Buffer

Per: HwTq10MeasPer2

Design Rationale

None

Server Runnables

HwTq10MeasHwTq10AutTrim

Design Rationale

None

HwTq10MeasHwTq10ClrTrim

Design Rationale

None

HwTq10MeasHwTq10ReadTrim

Design Rationale

None

HwTq10MeasHwTq10TrimPrfmdSts

Design Rationale

None

HwTq10MeasHwTq10WrTrim

Design Rationale

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	StuckNoDataSeln	Type	Min	Max
Arguments Passed	NA	N/A	N/A	N/A
Return Value	MissMsgEna_Uls_T_u08	uint8	0	1

Design Rationale

This function is split from Per1 to reduce path count and cyclomatic complexity.

Local Function #2

Function Name	RngChk	Type	Min	Max
Arguments Passed	Temp_Cnt_T_u32	uint32	0	4294967295
Return Value	RngChk_Cnt_T_logl	boolean	TRUE	FALSE

Design Rationale

This function is split from Per1 to reduce path count and cyclomatic complexity.

Local Function #3

Function Name	CrcChk	Type	Min	Max
Arguments Passed	CalcdCrc_Cnt_T_u16	uint16	0	15
Arguments Passed	AntcptdCrc_Cnt_T_u16	uint16	0	15
Return Value	CRCFaildPrmByte_Cnt_T_u08	uint8	0	1

Design Rationale

This function is split from Per1 to reduce path count and cyclomatic complexity.

Known Limitations with Design

None.

UNIT TEST CONSIDERATION

Clear local buffer in the below path of the model has not been implemented, because it’s not required. Path : ES225A_HwTq10Meas/HwTq10Meas/HwTq10MeasPer1/Raw Data Processing/Clear Local Buffer

Abbreviations and Acronyms

Abbreviation or Acronym	Description
MDD	Module Design Document
DFD	Data Flow Diagram

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	EA4 Software Naming Conventions	01.01.00
4	Software Design and Coding Standards	2.1
5	FDD – ES225A_HwTq10Meas_Design	See Synergy sub project version

13.3 - HwTq10Meas_PeerReview

Overview

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

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

HwTq10Meas

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

ES225A_HwTq10Meas_Impl_1.0.0

Change Owner:

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

Pratik H Jadhav

Work CR ID:

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

EA4#15525

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

Yes

Integration Manual

Yes

Davinci 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 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

Yes

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

Yes

Comments:

File/folder structure is correct per documentation in

Yes

Comments:

TL109A_SwcSuprt

General Notes / Comments:

Review Board:

Change Owner:

Pratik Jadhav

Review Date :

01/12/18

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

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

Sheet 3: Davinci Files

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

Yes

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

Yes

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

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

N/A

Comments: initial version

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

file) in all areas where arxml was changed and/or the

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

N/A

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using "Write (explicit)"

Yes

Comments:

and "Read (explicit by argument)"(List justification if not)

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Name and data type match DataDict.m file.

Per Instance Memory names and data types

Yes

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

Yes

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Pratik Jadhav

Review Date :

01/12/18

Component Type :

Application

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Xin Liu

Comments:

Other Reviewer(s):

Matt Leser

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

Sheet 4: Source Code

Rev 2.00

29-Nov-17

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

Source File Name:

HwTq10Meas

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

Header File Name:

NA

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)

MDD Name:

HwTq10Meas_MDD.docx

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

SWC Design Name:

ES225A_HwTq10Meas_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" 1.8.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 1.0

EA4 Software Naming Convention followed:

Version: 1.1

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

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.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

(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

N/A

Comments:

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

Initial Version

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

N/A

Comments:

All other includes are actually needed. (System includes

Yes

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:

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

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

Yes

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

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.

Yes

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

Yes

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

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

General Notes / Comments:

Review Board:

Change Owner:

Pratik jadhav

Review Date :

01/12/18

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Srikar

Comments:

Raghavendra

Integrator and or
SW lead:

Xin Liu

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

Matt Leser

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

Sheet 5: MDD

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

HwTq10Meas_MDD.docx

MDD Revision:

1

Source File Name:

HwTq10Meas

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

N/A

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

Yes

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the SWC

Yes

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Pratik Jadhav

Review Date :

01/12/18

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

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

Sheet 6: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

HwTq10Meas.c

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.04.00

Poly Space version:

Windows User: eg. 2013b

R2013b

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

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Review Board:

Change Owner:

Pratik Jadhav

Review Date :

01/12/18

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

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

Sheet 7: Integration Manual

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

kzshz2: Intended Use: Identify which version of the integration manual has been reviewed. 1

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Pratik Jadhav

Review Date :

01/12/18

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Xin Liu

Comments:

Other Reviewer(s):

Matt Leser

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

14 - Component Implementation

Component Implementation

Component Documentation

Specific Component Tools

Polyspace_Macros.html

14.1 - HwTq9Meas_IntegrationManual

Integration Manual

For

HwTq9Meas

VERSION: 1.0

DATE: 12-Jan-2018

Prepared By:

Software Engineering,

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Description	Author	Version	Date
Initial version	Krishna Anne	1.0	12-Jan-2018

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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	FDD – ES224A_HwTq9Meas_Design	See Synergy sub project version
2	Software Naming Conventions	01.01.00
3	Software Design and Coding Standards	2.1

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

Parameter	Notes	SWC
None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file in the FDD

Required Global Data Outputs

Refer DataDict.m file file in the FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
HwTq9MeasInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
HwTq9MeasPer1	None	RTE (2 ms)
HwTq9MeasPer2	None	RTE (100 ms)
HwTq9MeasHwTq9AutTrim_Oper	None	Server invocation
HwTq9MeasHwTq9ClrTrim_Oper	None	Server invocation
HwTq9MeasHwTq9ReadTrim_Oper	None	Server invocation
HwTq9MeasHwTq9TrimPrfmdSts_Oper	None	Server invocation
HwTq9MeasHwTq9WrTrim_Oper	None	Server invocation

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
HwTq9Meas_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

RTE NvM Blocks

Block Name

HwTq9Offs

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None.

Appendix

None

14.2 - HwTq9Meas_MDD

Module Design Document

For

HwTq9Meas

12-Jan-2018

Prepared By:

Software Engineering,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	Krishna Anne	1.0	12-Jan-2018

Table of Contents

1 Introduction 6

1.1 Purpose 6

1.2 Scope 6

2 HwTq9Meas High-Level Description 7

3 Design details of software module 8

3.1 Graphical representation of HwTq9Meas 8

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

3.2.2 Function level DFD 8

4 Constant Data Dictionary 9

4.1 Program (fixed) Constants 9

4.1.1 Embedded Constants 9

5 Software Component Implementation 10

5.1 Sub-Module Functions 10

5.1.1 Init: HwTq9MeasInit1 10

5.1.1.1 Design Rationale 10

5.1.2 Per: HwTq9MeasPer1 10

5.1.2.1 Design Rationale 10

5.1.3 Per: HwTq9MeasPer2 10

5.1.3.1 Design Rationale 10

5.2 Server Runnables 11

5.2.1 HwTq9MeasHwTq9AutTrim 11

5.2.1.1 Design Rationale 11

5.2.2 HwTq9MeasHwTq9ClrTrim 11

5.2.2.1 Design Rationale 11

5.2.3 HwTq9MeasHwTq9ReadTrim 11

5.2.3.1 Design Rationale 11

5.2.4 HwTq9MeasHwTq9TrimPrfmdSts 11

5.2.4.1 Design Rationale 11

5.2.5 HwTq9MeasHwTq9WrTrim 11

5.2.5.1 Design Rationale 11

5.3 Interrupt Functions 11

5.4 Module Internal (Local) Functions 12

5.4.1 Local Function #1 12

5.4.1.1 Design Rationale 12

5.4.2 Local Function #2 12

5.4.2.1 Design Rationale 12

5.4.3 Local Function #3 12

5.4.3.1 Design Rationale 12

6 Known Limitations with Design 13

7 UNIT TEST CONSIDERATION 14

Appendix A Abbreviations and Acronyms 15

Appendix B Glossary 16

Appendix C References 17

Introduction

Purpose

Refer to FDD.

Scope

HwTq9Meas High-Level Description

Refer to FDD

Design details of software module

Graphical representation of HwTq9Meas

Data Flow Diagram

Component level DFD

Refer to FDD

Function level DFD

Refer to FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
CRCTBLSIZE_CNT_U08	1	Cnt	16U

* Refer to FDD for other constant definitions

Software Component Implementation

Sub-Module Functions

Init: HwTq9MeasInit1

Design Rationale

None

Per: HwTq9MeasPer1

Design Rationale

Clear local buffer in the below path of the model has not been implemented, because it’s not required.

Path : ES224A_HwTq9Meas/HwTq9Meas/HwTq9MeasPer1/Raw Data Processing/Clear Local Buffer

Per: HwTq9MeasPer2

Design Rationale

None

Server Runnables

HwTq9MeasHwTq9AutTrim

Design Rationale

None

HwTq9MeasHwTq9ClrTrim

Design Rationale

None

HwTq9MeasHwTq9ReadTrim

Design Rationale

None

HwTq9MeasHwTq9TrimPrfmdSts

Design Rationale

None

HwTq9MeasHwTq9WrTrim

Design Rationale

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	StuckNoDataSeln	Type	Min	Max
Arguments Passed	NA	N/A	N/A	N/A
Return Value	MissMsgEna_Uls_T_u08	uint8	0	1

Design Rationale

This function is split from Per1 to reduce path count and cyclomatic complexity.

Local Function #2

Function Name	RngChk	Type	Min	Max
Arguments Passed	Temp_Cnt_T_u32	uint32	0	4294967295
Return Value	RngChk_Cnt_T_logl	boolean	TRUE	FALSE

Design Rationale

This function is split from Per1 to reduce path count and cyclomatic complexity.

Local Function #3

Function Name	CrcChk	Type	Min	Max
Arguments Passed	CalcdCrc_Cnt_T_u16	uint16	0	15
Arguments Passed	AntcptdCrc_Cnt_T_u16	uint16	0	15
Return Value	CRCFaildPrmByte_Cnt_T_u08	uint8	0	1

Design Rationale

This function is split from Per1 to reduce path count and cyclomatic complexity.

Known Limitations with Design

None.

UNIT TEST CONSIDERATION

Clear local buffer in the below path of the model has not been implemented, because it’s not required. Path : ES224A_HwTq9Meas/HwTq9Meas/HwTq9MeasPer1/Raw Data Processing/Clear Local Buffer

Abbreviations and Acronyms

Abbreviation or Acronym	Description
MDD	Module Design Document
DFD	Data Flow Diagram

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	EA4 Software Naming Conventions	01.01.00
4	Software Design and Coding Standards	2.1
5	FDD – ES224A_HwTq9Meas_Design	See Synergy sub project version

14.3 - HwTq9Meas_PeerReview

Overview

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

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

HwTq9Meas

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

ES224A_HwTq9Meas_Impl_1.0.0

Change Owner:

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

Krishna Anne

Work CR ID:

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

EA4#15171

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

Yes

Integration Manual

Yes

Davinci 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 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

Yes

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

Yes

Comments:

File/folder structure is correct per documentation in

Yes

Comments:

TL109A_SwcSuprt

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/12/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Pratik Jadhav

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

Sheet 3: Davinci Files

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

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

N/A

Comments:

versions (If available) and changes match changes

Initial version

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

file) in all areas where arxml was changed and/or the

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

N/A

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using "Write (explicit)"

Yes

Comments:

and "Read (explicit by argument)"(List justification if not)

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Name and data type match DataDict.m file.

Per Instance Memory names and data types

Yes

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

Yes

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/12/18

Component Type :

Application

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Xin Liu

Comments:

Other Reviewer(s):

Pratik Jadhav

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

Sheet 4: Source Code

Rev 2.00

29-Nov-17

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

Source File Name:

HwTq9Meas

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

Header File Name:

NA

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

MDD Name:

HwTq9Meas_MDD

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

SWC Design Name:

ES224A_HwTq9Meas_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" 1.6.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 1.0

EA4 Software Naming Convention followed:

Version: 1.1

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

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.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

(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

N/A

Comments:

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

Initial version

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

N/A

Comments:

All other includes are actually needed. (System includes

Yes

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

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

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

Yes

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

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.

Yes

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

Yes

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

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

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/12/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Srikar

Comments:

Raghavendran

Integrator and or
SW lead:

Xin Liu

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

Pratik Jadhav

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

Sheet 5: MDD

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

HwTq9Meas_MDD

MDD Revision:

1

Source File Name:

HwTq9Meas

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

N/A

Comments:

Initial version

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

Yes

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the SWC

Yes

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/12/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Pratik Jadhav

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

Sheet 6: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

HwTq9Meas

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.04.00

Poly Space version:

Windows User: eg. 2013b

R2013b

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

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Initial version

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/12/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Pratik Jadhav

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

Sheet 7: Integration Manual

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

kzshz2: Intended Use: Identify which version of the integration manual has been reviewed. 1

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

Initial version

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/12/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Pratik Jadhav

Integrator and or
SW lead:

Xin Liu

Comments:

Other Reviewer(s):

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

14.4 - Polyspace_Macros

PolySpace Viewer Excel importation macros

Reports can be generated from all Polyspace txt file format results. These are generated by the Polyspace Verifier during a code verification, the export option in the Polyspace verification environment, or from the command line using the "gen-excel-files" command.

Version 5.3.3

15 - Component Implementation

Component Implementation

Component Documentation

15.1 - HwTqArbn_ Review

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES228C_HwTqArbn_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. 1.0.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. Matthew Leser

Work CR ID:

EA4#9633

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci 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:

Matthew Leser

Review Date :

03/22/17

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Shawn Penning

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

N/A

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file

Calibration port initialization values match

Yes

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

Yes

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Matthew

Review Date :

03/22/17

Component Type :

Application

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

HwTqArbn.c

Source File Revision:

1

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:

HwTqArbn_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

ES228C_HwTqArbn_Design

Revision:

1.0.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

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.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version:

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

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

Yes

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:

Matthew Leser

Review Date :

03/22/17

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Shawn Penning

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

HwTqArbn_MDD.docx

MDD Revision:

1

Source File Name:

CDD_HwTqArbn.c

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

N/A

Comments: Initial Version

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

03/22/17

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Shawn Penning

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_MotAgArbn.c

Source File Revision:

2

Source File Name:

CDD_MotAgArbn_MotCtrl.c

Source File Revision:

2

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

Draft 1.2

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

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_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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Matthew Leser

Review Date :

03/22/17

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Shawn Penning

Sheet 7: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments: Initial Version

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:

Matthew Leser

Review Date :

03/22/17

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Shawn Penning

15.2 - HwTqArbn_IntegrationManual

Integration Manual

For

HwTqArbn

VERSION: 1.0

DATE: 21-Feb-2017

Prepared By:

Matthew Leser,

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	ML	1.0	21-Feb-2017

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 Dependencies 7

3.1 SWCs 7

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

4 Configuration REQUIREMeNTS 8

4.1 Build Time Config 8

4.2 Configuration Files to be provided by Integration Project 8

4.3 Da Vinci Parameter Configuration Changes 8

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
	<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.	Title	Version
<1>	<MDD Guidelines>	Process 04.02.00
<2>	<Software Naming Conventions>	Process 04.02.00
<3>	<Coding standards>	Process 04.02.00
<4>	FDD – ES228C_HwTqArbn_Design	See Synergy Subproject version

Dependencies

SWCs

Module	Required Feature
None

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

HwTqArbnPer1()

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer .m file

Required Global Data Outputs

Refer .m file

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
HwTqArbnInit1	None	RTE

Runnable	Scheduling Requirements	Trigger
HwTqArbnPer1	None	2 ms

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

15.3 - HwTqArbn_MDD

Module Design Document

For

HwTqArbn

Feb 21, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Matthew Leser,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	ML	1.0	21-Feb-2017

Table of Contents

1 Introduction 6

1.1 Purpose 6

1.2 Scope 6

2 HwTqArbn & High-Level Description 7

3 Design details of software module 8

3.1 Graphical representation of HwTqArbn 8

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

3.2.2 Function level DFD 8

4 Constant Data Dictionary 9

4.1 Program (fixed) Constants 9

4.1.1 Embedded Constants 9

5 Software Component Implementation 10

5.1 Sub-Module Functions 10

5.1.1 Init: HwTqArbnInit1 10

5.1.1.1 Design Rationale 10

5.1.1.2 Module Outputs 10

5.1.2 Per: HwTqArbnPer1 10

5.1.2.1 Design Rationale 10

5.1.2.2 (Processing of function)……… 10

5.2 Server Runables 10

5.3 Interrupt Functions 10

5.4 Module Internal (Local) Functions 10

5.4.1 Local Function #1 10

5.4.1.1 Design Rationale 10

5.4.1.2 Processing 10

5.4.2 Local Function #2 11

5.4.2.1 Design Rationale 11

5.4.2.2 Processing 11

5.5 GLOBAL Function/Macro Definitions 11

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Appendix A Abbreviations and Acronyms 14

Appendix B Glossary 15

Appendix C References 16

Introduction

Purpose

Scope

HwTqArbn & High-Level Description

Refer FDD.

Design details of software module

<The Data Flow Diagrams should be created in the absence of this representation with the FDD.>

Graphical representation of HwTqArbn

Data Flow Diagram

Refer FDD

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
BITMASKA_ULS_U08	1	Cnt	0x01
BITMASKB_ULS_U08	1	Cnt	0x02
BITMASKC_CNT_U08	1	Cnt	0x04
BITMASKD_CNT_U08	1	Cnt	0x08

Software Component Implementation

Sub-Module Functions

Init: HwTqArbnInit1

Design Rationale

Init1 function is created so that it will allow a RTE model to be created in the AUTOSAR tools which allows Per-Instance Memory and calibration definition needs. The initialization function is doing nothing

Module Outputs

None

Per: HwTqArbnPer1

Design Rationale

None

(Processing of function)………

Refer FDD

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	HwTqSigAvl	Type	Min	Max
Arguments Passed	HwTqRollgCntr_Cnt_T_u08	uint8	0	255
	HwTqQlfr_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	CorrlSig_Cnt_T_logl	boolean	FALSE	TRUE
	*RollgCntrPrev_Cnt_T_u08	uint8	0	255
	*StallCntr_Cnt_T_u08	uint8	0	255
Return Value	HwTqArbnAvl_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

None

Processing

None

Local Function #2

Function Name	HwTqContrbn	Type	Min	Max
Arguments Passed	HwTqAvl_Cnt_T_logl	boolean	FALSE	TRUE
	HwTqContrbn_HwNwtMtr_T_f32	float32	0	10
	*HwTqNumCntrbn_HwNwtMtr_T_f32	float32	-40	40
	*HwTqDenomCntrbn_Uls_T_f32	float32	0	4
Return Value	None

Design Rationale

None

Processing

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	Software Naming Conventions.doc	2.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES228C_HwTqArbn_Design	See Synergy Subproject verison

16 - Component Implementation

Component Implementation

Component Documentation

16.1 - HwTqCorrln_ Review

Overview

Summary Sheet
Synergy Project
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES229C_HwTqCorrln_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. 1.1.0

Change Owner:

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

Work CR ID:

EA4#11134

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci 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:

Matthew Leser

Review Date :

04/18/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

HwTqCorrln.c

Source File Revision:

1

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:

HwTqCorrln_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

ES229C_HwTqCorrln_Design

Revision:

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

Yes

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

N/A

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

Yes

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:

Matthew Leser

Review Date :

04/18/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

HwTqCorrln.c

Source File Revision:

2

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

Draft 1.2

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

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

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

No QAC done on this component as this was done using new component process/script

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:

Matthew Leser

Review Date :

04/18/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

16.2 - HwTqCorrln_IntegrationManual

Integration Manual

For

HwTqCorrln

VERSION: 1.0

DATE: 8-March-2017

Prepared By:

Matthew Leser,

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	ML	1.0	08-March-2017

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 Dependencies 7

3.1 SWCs 7

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

4 Configuration REQUIREMeNTS 8

4.1 Build Time Config 8

4.2 Configuration Files to be provided by Integration Project 8

4.3 Da Vinci Parameter Configuration Changes 8

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
	<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.	Title	Version
<1>	<MDD Guidelines>	Process 04.02.00
<2>	<Software Naming Conventions>	Process 04.02.00
<3>	<Coding standards>	Process 04.02.00
<4>	FDD – ES229C_HwTqCorrln_Design	See Synergy Subproject version

Dependencies

SWCs

Module	Required Feature
None

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

HwTqCorrlnPer1()

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer .m file

Required Global Data Outputs

Refer .m file

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
HwTqCorrlnInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
HwTqCorrlnPer1	None	2 ms

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

16.3 - HwTqCorrln_MDD

Module Design Document

For

HwTqCorrln

March 8, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Matthew Leser,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	ML	1.0	08-March-2017

Table of Contents

1 Introduction 6

1.1 Purpose 6

1.2 Scope 6

2 HwTqCorrln & High-Level Description 7

3 Design details of software module 8

3.1 Graphical representation of HwTqCorrln 8

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

3.2.2 Function level DFD 8

4 Constant Data Dictionary 9

4.1 Program (fixed) Constants 9

4.1.1 Embedded Constants 9

5 Software Component Implementation 10

5.1 Sub-Module Functions 10

5.1.1 Init: HwTqCorrlnInit1 10

5.1.1.1 Design Rationale 10

5.1.1.2 Module Outputs 10

5.1.2 Per: HwTqCorrlnPer1 10

5.1.2.1 Design Rationale 10

5.1.2.2 (Processing of function)……… 10

5.2 Server Runnable 10

5.3 Interrupt Functions 10

5.4 Module Internal (Local) Functions 10

5.4.1 Local Function #1 10

5.4.1.1 Design Rationale 10

5.4.1.2 Processing 10

5.4.2 Local Function #2 11

5.4.2.1 Design Rationale 11

5.4.2.2 Processing 11

5.4.3 Local Function #3 11

5.4.3.1 Design Rationale 11

5.4.3.2 Processing 11

5.4.4 Local Function #4 11

5.4.4.1 Design Rationale 11

5.4.4.2 Processing 11

5.4.5 Local Function #5 12

5.4.5.1 Design Rationale 12

5.4.5.2 Processing 12

5.5 GLOBAL Function/Macro Definitions 12

6 Known Limitations with Design 13

7 UNIT TEST CONSIDERATION 14

Appendix A Abbreviations and Acronyms 15

Appendix B Glossary 16

Appendix C References 17

Introduction

Purpose

Scope

HwTqCorrln & High-Level Description

Refer FDD.

Design details of software module

<The Data Flow Diagrams should be created in the absence of this representation with the FDD.>

Graphical representation of HwTqCorrln

Data Flow Diagram

Refer FDD

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
BITSHIFTB_CNT_U08	1	CNT	1U
BITSHIFTC_CNT_U08	1	CNT	2U
BITSHIFTD_CNT_U08	1	CNT	3U
BITSHIFTAC_CNT_U08	1	CNT	1U
BITSHIFTAD_CNT_U08	1	CNT	2U
BITSHIFTBC_CNT_U08	1	CNT	3U
BITSHIFTBD_CNT_U08	1	CNT	4U
BITSHIFTCD_CNT_U08	1	CNT	5U
DHWTQCORRLNIMDTCORRLNSTSMINLMT_CNT_U08	1	CNT	0U
DHWTQCORRLNIMDTCORRLNSTSMAXLMT_CNT_U08	1	CNT	63U

Software Component Implementation

Sub-Module Functions

Init: HwTqCorrlnInit1

Design Rationale

Init1 function is created so that it will allow a RTE model to be created in the AUTOSAR tools which allows Per-Instance Memory and calibration definition needs. The initialization function is doing nothing

Module Outputs

None

Per: HwTqCorrlnPer1

Design Rationale

None

(Processing of function)………

Refer FDD

Server Runnable

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	HwTqSigAvl	Type	Min	Max
Arguments Passed	HwTqRollgCntr_Cnt_T_u08	uint8	0	255
	HwTqQlfr_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	*RollgCntrPrev_Cnt_T_u08	uint8	0	255
	*StallCntr_Cnt_T_u08	uint8	0	255
Return Value	SigAvl_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

None

Processing

None

Local Function #2

Function Name	HwTqCorrlnFunc	Type	Min	Max
Arguments Passed	Sig1HwNwtMtr_T_f32	float32	-10	10
	Sig2HwNwtMtr_T_f32	float32	-10	10
	*SigCorrln_Cnt_T_u08	uint8	0	1
Return Value	SigCorrln_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

None

Processing

None

Local Function #3

Function Name	LongTermCorrln	Type	Min	Max
Arguments Passed	HwTqCorrln_Cnt_T_logl	boolean	FALSE	TRUE
	NtcNr_Cnt_T_enum	enum	NTCNR_0X070	NTCNR_0X07A
	NtcStInfo_Cnt_T_u08	uint8	0	63
Return Value	HwTqNotFaild_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

None

Processing

None

Local Function #4

Function Name	ANDFunc	Type	Min	Max
Arguments Passed	Inp1_Cnt_T_logl	boolean	FALSE	TRUE
	Inp2_Cnt_T_logl	boolean	FALSE	TRUE
	Inp3_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	Outp1_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

This function was added to reduce path count.

Processing

None

Local Function #5

Function Name	ORFunc	Type	Min	Max
Arguments Passed	Inp1_Cnt_T_logl	boolean	FALSE	TRUE
	Inp2_Cnt_T_logl	boolean	FALSE	TRUE
	Inp3_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	Outp1_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

This function was added to reduce path count.

Processing

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES229C_HwTqCorrln_Design	See Synergy Subproject verison

17 - Component Implementation

Component Implementation

Component Documentation

17.1 - McuDiagc_IntegrationManual

Integration Manual

For

McuDiagc

VERSION: 4.0

DATE: 10-Dec-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.	Description	Author	Version	Date
1	Initial version	Selva	1.0	29-Mar-2016
2	Added diagnostic for 2 milli second to Motor Control	Avinash James	2.0	22-Jun-2016
3	Optimized the diagnostic and removed periodic 3	Avinash James	3.0	28-Sep-2016
4	Added micro diag error injection build config param	Avinash James	4.0	10-Dec-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional 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	FDD – ES002A McuDiagc	See Synergy subproject version
2	Software Naming Conventions	Process 04.02.01
3	Software Coding Standards	Process 04.02.01

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

MCUDIAGCERRINJ

STD_OFF for other builds

STD_ON for uDiag test builds

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

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
McuDiagcInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
McuDiagcPer1	None	*MotorControl ISR2**
McuDiagcPer2	None	RTE (2 ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotCtrl_START_SEC_CODE	Code section for Motor Control scheduled functions	Constants are defined at function level. Memory mapping need to be adjusted accordingly.

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

17.2 - McuDiagc_MDD

Module Design Document

For

McuDiagc

Sep 28, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	Selva Sengottaiyan	1.0	29-Mar-2016
Updated for the 2Millisecond to MotorControl Diagnostic and changed NTC logic	Avinash James	2.0	22-Jun-2016
Optimized the diagniostics and removed periodic 3	Avinash James	3.0	28-Sep-2016

Table of Contents

1 Introduction 5

1.1 Purpose 5

2 McuDiagc & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of McuDiagc 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: McuDiagcInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: McuDiagcPer1 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.1.3 Per: McuDiagcPer2 9

5.1.3.1 Design Rationale 9

5.1.3.2 Store Module Inputs to Local copies 9

5.1.3.3 (Processing of function)……… 9

5.1.3.4 Store Local copy of outputs into Module Outputs 10

5.2 Server Runnable 10

5.3 Interrupt Functions 10

5.4 Module Internal (Local) Functions 10

5.5 GLOBAL Function/Macro Definitions 10

6 Known Limitations with Design 11

7 Outputs are not range limited as it is intentional and it is expected to go full range as it is a rolling counterUNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 16

Introduction

Purpose

Module design document for Micro Controller Diagnostics

McuDiagc & High-Level Description

Refer the Design.

Design details of software module

Graphical representation of McuDiagc

Data Flow Diagram

Component level DFD

N/A

Function level DFD

N/A

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
FASTLOOPCNTRENGMAX_CNT_U16	1	Cnt	65535
FASTLOOPCNTRENGMIN_CNT_U16	1	Cnt	0
ROLLOVROFFS_CNT_U16	1	Cnt	65535U
ROLLOVRCHK_CNT_U16	1	Cnt	32767U

LOOPCNTR2MILLISECMOTCTRLDIFFMIN_CNT_U16	1	Cnt	0U
Refer .m file

Software Component Implementation

Sub-Module Functions

The sub-module functions are grouped based on similar functionality that needs to be executed in a given “State” of the system (refer States and Modes). For a given module, the MDD will identify the type and number of sub-modules required. The sub-module types are described below.

Init: McuDiagcInit1

Design Rationale

Refer to FDD

Module Outputs

Refer to FDD

Per: McuDiagcPer1

Design Rationale

None

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD0

Store Local copy of outputs into Module Outputs

Refer to FDD

Per: McuDiagcPer2

Design Rationale

None

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD0

Store Local copy of outputs into Module Outputs

Refer to FDD

Server Runnable

None

Interrupt Functions

None

Module Internal (Local) Functions

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

Outputs are not range limited as it is intentional and it is expected to go full range as it is a rolling counter

UNIT TEST CONSIDERATION

Overflow for the variable Rte_Pim_FastLoopCntrPrev, Rte_Pim_LoopCntr2MilliSecStore is intentional as this is used as a rolling counter.

Abbreviations and Acronyms

Abbreviation or Acronym	Description
DFD	Design functional diagram
MDD	Module design Document

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES002A McuDiagc	See Synergy subproject version

17.3 - McuDiagc_ReviewChecklist

Overview

Summary Sheet
Synergy Project
Source Code_Rte
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES002A_McuDiagc_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. 2.2.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. Avinash James

Work CR ID:

EA4#10059

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

Changed one global constant in the micro diag error injection

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:

Avinash James

Review Date :

02/28/17

Lead Peer Reviewer:

Shruthi Raghavan

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code_Rte

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_McuDiagc.c

Source File Revision:

7

Header File Name:

CDD_McuDiagc.h

Header File Revision:

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

MDD Name:

McuDiagc_MDD

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

ES002A_McuDiagc_Design

Revision:

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

Yes

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:

Removed all the existing req tags

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

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version:2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

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

No

Comments:

Intentional roll over allowed as per design

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:

Reviewed only for the changes

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:

Avinash James

Review Date :

02/28/17

Lead Peer Reviewer:

Shruthi Raghavan

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_McuDiagc_MotCtrl

Source File Revision:

3

Source File Name:

CDD_McuDiagc

Source File Revision:

7

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

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Avinash James

Review Date :

02/28/17

Lead Peer Reviewer:

Shruthi Raghavan

Approved by Reviewer(s):

Yes

Other Reviewer(s):

18 - Component Implementation

Component Implementation

Component Documentation

18.1 - MotAg2Meas_IntegrationManual

Integration Manual

For

MotAg2Meas

VERSION: 2.0

DATE: 19-Mar-2016

Prepared By:

Krishna Anne,

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	Sankardu Varadapureddi	1.0	28-Aug-2015
2	As per FDD V 3.1.0	Krishna Anne	2.0	19-Mar-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	FDD : ES241A_ MotAg2Meas_Design	See Synergy sub project version
2	Software Naming Conventions	Process 4.02.00
3	Software Design and Coding Standards	Process 4.02.00

Dependencies

SWCs

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file in the FDD

Required Global Data Outputs

Refer DataDict.m file file in the FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotAg2MeasInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
MotAg2MeasPer1	None	RTE (2 ms)
MotAg2MeasEolPrmRead_Oper	None	On event
MotAg2MeasEolPrmWr_Oper	None	On event

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

Refer .m file.

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None.

Appendix

None

18.2 - MotAg2Meas_MDD

Module Design Document

For

MotAg2Meas

Apr 22, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Krishna Anne,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Sankardu Varadapureddi	1	28-Aug-2015
Updates of FDD v 1.5.0 and 1.6.0	Krishna Anne	2	16-Mar-2016
Updates of FDD v 1.7.0	Krishna Anne	3	14-Apr-2016
Fixed issue found w.r.t MotPosTestOk_Cnt_T_lgc during manual inspection	Krishna Anne	4	14-Apr-2016

Table of Contents1 Introduction 5

1.1.1.1 Purpose 5

1.1.1.2 Scope 5

2 MotAg2Meas High-Level Description 6

3 Design details of software module 7

3.1.1.1 Graphical representation of MotAg2Meas 7

3.1.1.2 Data Flow Diagram 7

3.1.2 Component level DFD 7

3.1.3 Function level DFD 7

4 Constant Data Dictionary 8

4.1.1.1 Program (fixed) Constants 8

4.1.2 Embedded Constants 8

5 Software Component Implementation 9

5.1.1.1 Sub-Module Functions 9

5.1.1.2 Init: MotAg2MeasInit1 9

5.1.1.3 Design Rationale 9

5.1.1.4 Module Outputs 9

5.1.1.5 Per: MotAg2MeasPer1 9

5.1.1.6 Design Rationale 9

5.1.1.7 9

5.1.1.8 (Processing of function)……… 9

5.1.1.9 Store Local copy of outputs into Module Outputs 9

5.1.1.10 Server Runables 9

5.1.1.11 MotAg2MeasEolPrmRead_Oper 9

5.1.1.12 Design Rationale 9

5.1.1.13 Store Module Inputs to Local copies 9

5.1.1.14 (Processing of function)……… 9

5.1.1.15 MotAg2MeasEolPrmWr_Oper 10

5.1.1.16 Design Rationale 10

5.1.1.17 Store Module Inputs to Local copies 10

5.1.1.18 (Processing of function)……… 10

5.1.1.19 Interrupt Functions 10

5.1.1.20 Module Internal (Local) Functions 10

5.1.1.21 GLOBAL Function/Macro Definitions 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

Scope

MotAg2Meas High-Level Description

Refer to FDD

Design details of software module

Graphical representation of MotAg2Meas

Data Flow Diagram

Refer FDD

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
SINCOSMINERR_CNT_U08	1	Cnt	0x01
SINCOSMAXERR_CNT_U08	1	Cnt	0x02
ROLLCNTMAX_CNT_U08	1	Cnt	255
MOTAG2VLTGSQDMIN	1	Volt	0.0F
MOTAG2VLTGSQDMAX	1	Volt	25.0F

Software Component Implementation

Sub-Module Functions

Init: MotAg2MeasInit1

Design Rationale

Refer FDD for the functionality.

Module Outputs

Refer FDD

Per: MotAg2MeasPer1

Design Rationale

Refer FDD for the functionality.

In the path ES241A_MotAg2Meas/MotAg2Meas/MotAg2MeasPer1/AnalogMsbDiagnostics of the FDD model, the 4 input OR block would be redundantly doing the same functionality as done in the TestFail block of respective if action sub-system.

Store Module Inputs to Local copies

Refer FDD

(Processing of function)………

Refer FDD

Store Local copy of outputs into Module Outputs

Refer FDD

Server Runables

MotAg2MeasEolPrmRead_Oper

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Refer FDD

MotAg2MeasEolPrmWr_Oper

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Refer FDD

Interrupt Functions

None

Module Internal (Local) Functions

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions.doc	EA4 01.00.00
4	Software Design and Coding Standards.doc	2.1
5	FDD : ES241A_ MotAg2Meas_Design	See Synergy sub project version

18.3 - MotAg2Meas_Review

Overview

Summary Sheet
Synergy Project
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES241A_MotAg2Meas_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. ES241A_MotAg2Meas_Impl_1.6.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. Krishna Anne

Work CR ID:

EA4#8971

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

Reviewd changes alone

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:

Krishna Anne

Review Date :

01/04/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

MotAg2Meas.c

Source File Revision:

7

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:

MotAg2Meas_MDD.docx

Revision:

4

FDD/SCIR/DSR/FDR/CM Name:

ES241A_MotAg2Meas_Design

Revision:

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

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

magic numbers: [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsiged conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

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:

Krishna Anne

Review Date :

01/04/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

MotAg2Meas.c

Source File Revision:

7

Source File Name:

Source File Revision:

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Krishna Anne

Review Date :

01/04/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

18.4 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
ES241A	113	MotAg2Meas.c	MotAg2MeasPer1	1059	I
ES241A	133	MotAg2Meas.c	MotAg2MeasPer1	990	I
ES241A	132	MotAg2Meas.c	MotAg2MeasPer1	990	I
ES241A	117	MotAg2Meas.c	MotAg2MeasPer1	1005	I
ES241A	137	MotAg2Meas.c	MotAg2MeasPer1	976	I
ES241A	65	MotAg2Meas.c	MotAg2MeasPer1	928	I
ES241A	135	MotAg2Meas.c	MotAg2MeasEolPrmRead_Oper	735-744	I
ES241A	134	MotAg2Meas.c	MotAg2MeasPer1	985	I
ES241A	83	MotAg2Meas.c	MotAg2MeasPer1	1008	I
ES241A	139	MotAg2Meas.c	MotAg2MeasPer1	935-996	I
ES241A	48	MotAg2Meas.c	MotAg2MeasPer1	926	I
ES241A	49	MotAg2Meas.c	MotAg2MeasPer1	927	I
ES241A	146	MotAg2Meas.c	MotAg2MeasPer1	931	I
ES241A	145	MotAg2Meas.c	MotAg2MeasPer1	930	I
ES241A	142	MotAg2Meas.c	MotAg2MeasPer1	1025	I
ES241A	143	MotAg2Meas.c	MotAg2MeasPer1	1052-1056	I
ES241A	140	MotAg2Meas.c	MotAg2MeasInit1	828	I
ES241A	141	MotAg2Meas.c	MotAg2MeasInit1	838-844	I
ES241A	121	MotAg2Meas.c	MotAg2MeasPer1	1011	I
ES241A	123	MotAg2Meas.c	MotAg2MeasPer1	1014	I
ES241A	124	MotAg2Meas.c	MotAg2MeasPer1	1020	I
ES241A	114	MotAg2Meas.c	MotAg2MeasPer1	1060	I
ES241A	32	MotAg2Meas.c	MotAg2MeasEolPrmWr_Oper	784-794	I
ES241A	16	MotAg2Meas.c	MotAg2MeasPer1	1061	I
ES241A	51	MotAg2Meas.c	MotAg2MeasPer1	1058	I
ES241A	131	MotAg2Meas.c	MotAg2MeasPer1	935-996	I
ES241A	136	MotAg2Meas.c	MotAg2MeasPer1	994	I

19 - Component Implementation

Component Implementation

Component Documentation

19.1 - MotAg5Meas_IntegrationManual

Integration Manual

For

MotAg5Meas

VERSION: 1.0

DATE: 31-JUL-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	Shruthi Raghavan	1.0	31-Jul-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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

Sl.No.	Title	Version
1	EA4 Software Naming Conventions	01.01.00
2	EA4 Common Naming Conventions	01.01.00
3	Software Design and Coding Standards	2.1
4	ES242A_MotAg5Meas_Design	See Synergy design Subproject version

Dependencies

SWCs

Module	Required Feature
None

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

MotAg5MeasPer2

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter

Notes

SWC

/Nexteer/MotAg5Meas/

MotAg5MeasGeneral/MotAg5PrtclFlt

NTC Number for Protocol Fault in MotAg5Meas component. Range is NTCNR_0X083 to NTCNR_0X08A

ES242A

MotAg5Meas

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer FDD DataDict.m file

Required Global Data Outputs

Refer FDD DataDict.m file

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotAg5MeasInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
MotAg5MeasPer1	None	RTE (2ms)
MotAg5MeasPer3	None	RTE (4ms)
MotAg5MeasPer2	None	ISR(MotCtrlRate)
MotAg5EolPrmRead	None	On invocation
MotAg5EolPrmWr	None	On invocation

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotCtrl_START_SEC_CODE	Code section for Motor Control scheduled functions
CDD_MotAg5Meas_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

MotAg5EolPrm

MotAg5StVari

*See DataDict.m for details

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

19.2 - MotAg5Meas_MDD

Module Design Document

For

MotAg5Meas

Oct 16, 2017

Prepared By:

Shruthi Raghavan,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	Shruthi Raghavan	1	15-Jul-2015
Updated Graphical Diagram for input change : from MotAg5Mecl to MotAg5RawMecl	Shruthi Raghavan	2	16-Oct-2017

Table of Contents

1 Introduction 5

1.1 Purpose 5

2 MotAg5Meas & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of MotAg5Meas 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: MotAg5MeasInit1 9

5.1.1.1 Design Rationale 9

5.1.2 Per: MotAg5MeasPer1 9

5.1.2.1 Design Rationale 9

5.1.3 Per: MotAg5MeasPer2 9

5.1.3.1 Design Rationale 9

5.1.4 Per: MotAg5MeasPer3 9

5.1.4.1 Design Rationale 9

5.2 Server Runables 9

5.2.1 MotAg5EolPrmRead 9

5.2.1.1 Design Rationale 9

5.3 Module Internal (Local) Functions 9

5.3.1 Local Function #1 9

5.4 GLOBAL Function/Macro Definitions 10

5.4.1 GLOBAL Function #1 10

5.4.1.1 Design Rationale 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

Module design document for MotAg5Meas

MotAg5Meas & High-Level Description

MotAg5Meas funtion shall compute motor angle from Sine and Cosine ADC signals.

Design details of software module

Graphical representation of MotAg5Meas

Data Flow Diagram

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
ADCLORNGFAILDBIT_CNT_U08	1	Cnt	0U
ADCHIRNGFAILDBIT_CNT_U08	1	Cnt	1U

Software Component Implementation

Sub-Module Functions

Init: MotAg5MeasInit1

Refer FDD simulink model for design details.

Design Rationale

‘LpFil Init’ block in the FDD does not use ‘FilLpInit’ library block due to a design limitation with the Library block (see ‘Known limitations with design’). However, code has no such limitation, so the code uses ‘FilLpInit’ block instead of initializing the gain using ‘FilLpUpdGain’ block first and then updating the state variable values.

Per: MotAg5MeasPer1

Refer FDD simulink model for design details.

Design Rationale

Rollover on Rte_Pim_MotAg5PrevRollgCntr is intentional, as it is used to reset the rolling counter back to zero when it reaches its max value of 255. The functionality remains the same as in the FDD.

Per: MotAg5MeasPer2

Design Rationale

Refer FDD Simulink model

Per: MotAg5MeasPer3

Design Rationale

Refer FDD Simulink model

Server Runables

MotAg5EolPrmRead_Oper

Design Rationale

Refer FDD Simulink model

MotAg5EolPrmWr_Oper

Design Rationale

Refer FDD Simulink model

Module Internal (Local) Functions

Local Function #1

Function Name	N/A	Type	Min	Max
Arguments Passed	None	-	-	-
Return Value	N/A	-	-	-

GLOBAL Function/Macro Definitions

GLOBAL Function #1

Function Name	N/A	Type	Min	Max
Arguments Passed	Nones	-	-	-
Return Value	N/A	-	-	-

Design Rationale

Known Limitations with Design

The model does not use ‘FilLpInit’ because that library block cannot accept a variable as input for initialization of the state variable. So they initialize the gain first in the model using ‘FilLpUpdGain’ and then initialize the state variable with the required non-constant input value to the sub-block.
The model uses SCAGCON_ULS_F32 in simulation only blocks but lists this in the Data dictionary m file. However, this isnt required for implementation.

UNIT TEST CONSIDERATION

Some overflows are intentional. This is indicated as such in the code using comments.

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.4.0 R4.0 Rev 3
2	MDD Guideline	EA4 01.00.01
3	EA4 Software Naming Conventions.doc	01.01.00
4	Software Design and Coding Standards.doc	2.1

19.3 - MotAg5Meas_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
Source Code1
MDD
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. MotAg5Meas

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. ES242A_MotAg5Meas_Impl_1.2.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. Shruthi Raghavan

Work CR ID:

EA4#15815

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci 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:

Shruthi Raghavan

Review Date :

10/16/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

no change

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

no change

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

*

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

no change

General Notes / Comments:

Check with Kevin for if Write verification check in Nvm should be set to true/false/default : Preferably False, but it resets to default, so left at default. 8/2/2017

Is the config param supposed to be 'global' in the fdd? : Yes, but its not used by any other component 7/31/2017

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:

Shruthi Raghavan

Review Date :

10/16/17

Component Type :

CDD

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAg5Meas.c

Source File Revision:

2

Header File Name:

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

MDD Name:

MotAg5Meas_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES242A_MotAg5Meas_Design

Revision:

1.3.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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

N/A

Comments:

Not necessary for RTE file

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

Yes

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

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.

Yes

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

Yes

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:

Shruthi Raghavan

Review Date :

10/16/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: Source Code1

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAg5Meas_MotCtrl.c

Source File Revision:

3

Header File Name:

CDD_MotAg5Meas.h

Header File Revision:

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

MDD Name:

MotAg5Meas_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES242A_MotAg5Meas_Design

Revision:

1.3.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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:

not part of change. Retained from before

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

not part of change. Retained from before

Software Design and Coding Standards followed:

Version: 2.1

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

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

N/A

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

not part of change. Retained from before.

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

Yes

Comments:

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

overflow is intentional in design

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:

Shruthi Raghavan

Review Date :

10/16/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

MotAg5Meas_MDD.docx

MDD Revision:

2

Source File Name:

CDD_MotAg5Meas.c

Source File Revision:

2

Source File Name:

CDD_MotAg5Meas_MotCtrl.c

Source File Revision:

3

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Shruthi Raghavan

Review Date :

10/16/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_MotAg5Meas.c

Source File Revision:

2

Source File Name:

CDD_MotAg5Meas_MotCtrl.c

Source File Revision:

3

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

The overflow warnings in Polyspace were checked and verified to be OK

The uninitialized local variables orange checks are because of a TL109A issue and were verified OK

Manually changed Rte_Stubs.c and Rte_Stubs.h file for type change of size to uint16 (instead of unsigned long).

Also added extern declaration for the MemCpy function in Rte_Stubs.h

Updated ddtypes.py and ddtypes.pyc using UpdateDD.bat in TL109A_SwcSuprt/tools/resources/ for getting the range of NVM pims that use newer structure types

Deadcode in Polyspace is because the entire library function is not utilized due to the input range. This is ok. 10/3/2017

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:

Shruthi Raghavan

Review Date :

10/03/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

20 - Component Implementation

Component Implementation

Component Documentation

20.1 - MotAg6Meas_IntegrationManual

Integration Manual

For

MotAg6Meas

VERSION: 1.0

DATE: 31-JUL-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	Shruthi Raghavan	1.0	31-Jul-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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

Sl.No.	Title	Version
1	EA4 Software Naming Conventions	01.01.00
2	EA4 Common Naming Conventions	01.01.00
3	Software Design and Coding Standards	2.1
4	ES243A_MotAg6Meas_Design	See Synergy design Subproject Version

Dependencies

SWCs

Module	Required Feature
None

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

MotAg6MeasPer2

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter

Notes

SWC

/Nexteer/MotAg6Meas/

MotAg6MeasGeneral/MotAg6PrtclFlt

NTC Number for Protocol Fault in MotAg6Meas component. Range is NTCNR_0X083 to NTCNR_0X08A

ES243A

MotAg6Meas

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer FDD DataDict.m file

Required Global Data Outputs

Refer FDD DataDict.m file

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotAg6MeasInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
MotAg6MeasPer1	None	RTE (2ms)
MotAg6MeasPer3	None	RTE (4ms)
MotAg6MeasPer2	None	ISR(MotCtrl)
MotAg6EolPrmRead	None	On invocation
MotAg6EolPrmWr	None	On invocation

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotCtrl_START_SEC_CODE	Code section for Motor Control scheduled functions
CDD_MotAg6Meas_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

MotAg6EolPrm

MotAg6StVari

*See DataDict.m for details

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

20.2 - MotAg6Meas_MDD

Module Design Document

For

MotAg6Meas

Oct 16, 2017

Prepared By:

Shruthi Raghavan,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	Shruthi Raghavan	1	31-Jul-2017
Updated graphical representation to show input name change	Shruthi Raghavan	2	16-Oct-2017

Table of Contents

1 Introduction 5

1.1 Purpose 5

2 MotAg6Meas & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of MotAg6Meas 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: MotAg6MeasInit1 9

5.1.1.1 Design Rationale 9

5.1.2 Per: MotAg6MeasPer1 9

5.1.2.1 Design Rationale 9

5.1.3 Per: MotAg6MeasPer2 9

5.1.3.1 Design Rationale 9

5.1.4 Per: MotAg6MeasPer3 9

5.1.4.1 Design Rationale 9

5.2 Server Runables 9

5.2.1 MotAg6EolPrmRead 9

5.2.1.1 Design Rationale 9

5.2.2 MotAg6EolPrmWr 9

5.2.2.1 Design Rationale 9

5.3 Module Internal (Local) Functions 9

5.3.1 Local Function #1 9

5.4 GLOBAL Function/Macro Definitions 10

5.4.1 GLOBAL Function #1 10

5.4.1.1 Design Rationale 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

Module design document for MotAg6Meas

MotAg6Meas & High-Level Description

MotAg6Meas funtion shall compute motor angle from Sine and Cosine ADC signals.

Design details of software module

Graphical representation of MotAg6Meas

Data Flow Diagram

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
ADCLORNGFAILDBIT_CNT_U08	1	Cnt	0U
ADCHIRNGFAILDBIT_CNT_U08	1	Cnt	1U

Software Component Implementation

Sub-Module Functions

Init: MotAg6MeasInit1

Refer FDD simulink model for design details.

Design Rationale

‘LpFil Init’ block in the FDD does not use ‘FilLpInit’ library block due to a design limitation with the Library block (see ‘Known limitations with design’). However, code has no such limitation, so the code uses ‘FilLpInit’ block instead of initializing the gain using ‘FilLpUpdGain’ block first and then updating the state variable values.

Per: MotAg6MeasPer1

Refer FDD simulink model for design details.

Design Rationale

Rollover on Rte_Pim_MotAg6PrevRollgCntr is intentional, as it is used to reset the rolling counter back to zero when it reaches its max value of 255. The functionality remains the same as in the FDD.

Per: MotAg6MeasPer2

Design Rationale

Refer FDD simulink model for design details.

Per: MotAg6MeasPer3

Design Rationale

Refer FDD simulink model for design details.

Server Runables

MotAg6EolPrmRead

Design Rationale

MotAg6EolPrmWr

Design Rationale

Module Internal (Local) Functions

Local Function #1

Function Name	N/A	Type	Min	Max
Arguments Passed	None	-	-	-
Return Value	N/A	-	-	-

GLOBAL Function/Macro Definitions

GLOBAL Function #1

Function Name	N/A	Type	Min	Max
Arguments Passed	Nones	-	-	-
Return Value	N/A	-	-	-

Design Rationale

N/A

Known Limitations with Design

The model does not use ‘FilLpInit’ because that library block cannot accept a variable as input for initialization of the state variable. So they initialize the gain first in the model using ‘FilLpUpdGain’ and then initialize the state variable with the required non-constant input value to the sub-block.
The model uses SCAGCON_ULS_F32 in simulation only blocks but lists this in the Data dictionary m file. However, this isnt required for implementation.

UNIT TEST CONSIDERATION

Some overflows are intentional. This is indicated as such in the code using comments.

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.4.0 R4.0 Rev 3
2	MDD Guideline	EA4 01.00.01
3	EA4 Software Naming Conventions.doc	01.01.00
4	Software Design and Coding Standards.doc	2.1

20.3 - MotAg6Meas_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
Source Code1
MDD
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. MotAg6Meas

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. ES243A_MotAg6Meas_Impl_1.1.0

Change Owner:

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

Work CR ID:

EA4#15853

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci 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:

no change

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:

Shruthi Raghavan

Review Date :

10/16/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

N/A

Comments:

For components not using application data types, do all

N/A

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

no change

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

no change

General Notes / Comments:

Check with Kevin for if Write verification check in Nvm should be set to true/false/default : Preferably False, but it resets to default, so left at default. 8/2/2017

Is the config param supposed to be 'global' in the fdd? : Yes, but its not used by any other component 7/31/2017

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:

Shruthi Raghavan

Review Date :

10/16/17

Component Type :

CDD

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAg6Meas.c

Source File Revision:

2

Header File Name:

CDD_MotAg6Meas_Cfg_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. 1

MDD Name:

MotAg6Meas_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES243A_MotAg6Meas_Design

Revision:

1.4.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

N/A

Comments:

Not used in this file.

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

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

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:

Shruthi Raghavan

Review Date :

10/16/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: Source Code1

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAg6Meas_MotCtrl.c

Source File Revision:

2

Header File Name:

CDD_MotAg6Meas.h

Header File Revision:

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

MDD Name:

MotAg6Meas_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES243A_MotAg6Meas_Design

Revision:

1.4.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

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:

no change from previous version

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

no change from previous version

Software Design and Coding Standards followed:

Version: 2.1

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

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

N/A

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

Yes

Comments:

is per standard

no change from previous version

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,

Yes

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

Yes

Comments:

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

Overflow is intentional & output range is max of data type

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:

Shruthi Raghavan

Review Date :

10/16/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

MotAg6Meas_MDD.docx

MDD Revision:

2

Source File Name:

CDD_MotAg6Meas.c

Source File Revision:

2

Source File Name:

CDD_MotAg6Meas_MotCtrl.c

Source File Revision:

2

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Shruthi Raghavan

Review Date :

10/16/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_MotAg6Meas.c

Source File Revision:

2

Source File Name:

CDD_MotAg6Meas_MotCtrl.c

Source File Revision:

2

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

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 Analysis

Yes

Comments:

Compliance Guideline

see comments

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

no change from previous version

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

The overflow warnings in Polyspace were checked and verified to be OK

The uninitialized local variables orange checks are because of a TL109A issue and were verified OK

Manually changed Rte_Stubs.c and Rte_Stubs.h file for type change of size to uint16 (instead of unsigned long).

Also added extern declaration for the MemCpy function in Rte_Stubs.h

Updated ddtypes.py and ddtypes.pyc using UpdateDD.bat in TL109A_SwcSuprt/tools/resources/ for getting the range of NVM pims that use newer structure types

Deadcode in Polyspace is because the input to library function is never negative to the input range. This is ok.10/4/2017

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:

Shruthi Raghavan

Review Date :

10/16/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

21 - Component Implementation

Component Implementation

Component Documentation

21.1 - MotAgArbn_IntegrationManual

Integration Manual

For

MotAgArbn

VERSION: 2.0

DATE: 29-SEP-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	SB	1.0	06-Aug-2015
2	Updated the name of the runnable for the removed CDD_ prefix (per naming conventions)	Shruthi Raghavan	2.0	29-Sep-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	EA4 Software Naming Conventions	Process 04.02.00

2	FDD - ES248A_MotAgArbn_Design	See Synergy Subproject version

Dependencies

SWCs

Module	Required Feature
None

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

MotAgArbnPer1()

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer .m file

Required Global Data Outputs

Refer .m file

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotAgArbnInit1	None	Init(RTE)

Runnable	Scheduling Requirements	Trigger
MotAgArbnPer1	None	MOTCTRL ISR *2

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotCtrl_START_SEC_CODE	Code section for Motor Control scheduled functions

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

21.2 - MotAgArbn_MDD

Module Design Document

For

MotAgArbn

Sep 29, 2017

Prepared By:

Shruthi Raghavan,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	SB	1.0	05-Aug-2015
Updated per design vers. 1.2.0	ML	2.0	15-Feb-2017
Updated to remove the constants that have been renamed and added to DataDict.m file in design.	Shruthi Raghavan	3.0	29-Sep-2017

Table of Contents1 Introduction 4

Purpose 4

1.1 4

2 MotAgArbn & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of MotAgArbn 6

3.2 Data Flow Diagram 6

3.2.1 Component level DFD 6

3.2.2 Function level DFD 6

4 Constant Data Dictionary 7

4.1 Program (fixed) Constants 7

4.1.1 Embedded Constants 7

5 Software Component Implementation 8

5.1 Sub-Module Functions 8

5.1.1 Init: MotAgArbnInit1 8

5.1.1.1 Design Rationale 8

5.1.1.2 Module Outputs 8

5.1.2 Per: MotAgArbnPer1 8

5.1.2.1 Design Rationale 8

5.2 Server Runables 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 8

5.4.1 Local Function #1 8

5.4.1.1 Design Rationale 8

5.5 GLOBAL Function/Macro Definitions 8

6 Known Limitations with Design 9

7 UNIT TEST CONSIDERATION 10

Appendix A Abbreviations and Acronyms 11

Appendix B Glossary 12

Appendix C References 13

Introduction

Purpose

Module design document for MotAgArbn

MotAgArbn & High-Level Description

Refer FDD.

Design details of software module

Graphical representation of MotAgArbn

Data Flow Diagram

Refer FDD

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Refer .m file

Software Component Implementation

Sub-Module Functions

Init: MotAgArbnInit1

Design Rationale

Init1 function is created so that it will allow a RTE model to be created in the AUTOSAR tools which allows Per-Instance Memory and calibration definition needs. The initialization function is doing nothing

Module Outputs

None

Per: MotAgArbnPer1

Design Rationale

None

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	SigAvlyChk	Type	Min	Max
Arguments Passed	SigCorrChk_Cnt_T_u08	uint8	0U	2U
	SigRollgCntr_Cnt_T_u08	uint8	0U	255U
	SigQlfr_Cnt_T_enum	SigQlfr1	SIGQLFR_NORES	SIGQLFR_FAILD
	* PrevRollgCntr_Cnt_T_u08	uint8	0U	255U
	* StallCnt_Cnt_T_u08	uint8	0U	10U
Return Value	SigAvl_Cnt_T_lgc	boolean	FALSE	TRUE

Design Rationale

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	EA4 Software Naming Conventions.doc	EA4 01.01.00
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES248A_MotAgArbn_Design	See Synergy Subproject verison

21.3 - MotAgArbn_PeerReviewChecklist

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-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. MotAgArbn

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. ES248A_MotAgArbn_Impl_1.2.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. Shruthi Raghavan

Work CR ID:

EA4#15132

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci 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:

Shruthi Raghavan

Review Date :

09/29/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

PIMs still use uint8 datatype from DataTypes package that used to be in TL107A

For components not using application data types, do all

N/A

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

changed init function name to remove CDD_ prefix

Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

N/A

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

Yes

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Shruthi Raghavan

Review Date :

09/29/17

Component Type :

CDD

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Other Reviewer(s):

Brionna Spencer

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAgArbn.c

Source File Revision:

3

Header File Name:

N/A

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:

MotAgArbn_MDD.docx

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

ES248A_MotAgArbn_Design

Revision:

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

Yes

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

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

N/A

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

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:

Shruthi Raghavan

Review Date :

09/29/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

Sheet 5: Source Code1

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAgArbn_MotCtrl.c

Source File Revision:

3

Header File Name:

CDD_MotAgArbn.h

Header File Revision:

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

Header File Name:

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

MDD Name:

MotAgArbn_MDD.docx

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

ES248A_MotAgArbn_Design

Revision:

1.3.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

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.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

Yes

Comments:

is per standard

no change

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

Yes

Comments:

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

implicit (because it is always assigned to one of the 2 inputs)

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:

Shruthi Raghavan

Review Date :

09/29/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

Sheet 6: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

MotAgArbn_MDD.docx

MDD Revision:

3

Source File Name:

CDD_MotAgArbn.c

Source File Revision:

3

Source File Name:

CDD_MotAgArbn_MotCtrl.c

Source File Revision:

3

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:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Shruthi Raghavan

Review Date :

09/29/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

Sheet 7: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_MotAgArbn.c

Source File Revision:

3

Source File Name:

CDD_MotAgArbn_MotCtrl.c

Source File Revision:

3

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Shruthi Raghavan

Review Date :

09/29/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

Sheet 8: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Shruthi Raghavan

Review Date :

09/29/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

22 - Component Implementation

Component Implementation

Component Documentation

22.1 - MotAgCmp_DesignReview

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES247A_MotAgCmp_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. ES247A_MotAgCmp_Impl_1.5.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. Krishna Anne

Work CR ID:

EA4#8350

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci 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:

Krishna Anne

Review Date :

11/30/16

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

It uses the application type also

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Krishna Anne

Review Date :

11/30/16

Component Type :

CDD

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAgCmp.c

Source File Revision:

5

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:

MotAgCmp_MDD.doc

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

ES247A_MotAgCmp_Design

Revision:

1.7.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

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.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

N/A

Comments:

"magic numbers": [N12]

N/A for the changes

Memory mapping for non-RTE code

Yes

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:

Krishna Anne

Review Date :

11/30/16

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: Source Code1

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAgCmp_MotCtrl.c

Source File Revision:

6

Header File Name:

CDD_MotAgCmp.h

Header File Revision:

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

MDD Name:

MotAgCmp_MDD.doc

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

ES247A_MotAgCmp_Design

Revision:

1.7.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

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

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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:

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

N/A

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

N/A

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

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]

No range limiting is needed as the o/ps are full ranged

All code is mapped with FDD (all FDD

N/A

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:

Krishna Anne

Review Date :

11/30/16

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

MotAgCmp_MDD

MDD Revision:

3

Source File Name:

MotAgCmp.c

Source File Revision:

5

Source File Name:

CDD_MotAgCmp_MotCtrl.c

Source File Revision:

6

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

N/A

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

N/A

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Krishna Anne

Review Date :

11/30/16

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

N/A

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Krishna Anne

Review Date :

11/30/16

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 8: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

MotAgCmp.c

Source File Revision:

5

Source File Name:

CDD_MotAgCmp_MotCtrl.c

Source File Revision:

6

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

Draft_01

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Krishna Anne

Review Date :

11/30/16

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

22.2 - MotAgCmp_IntegrationManual

Integration Manual

For

MotAgCmp

VERSION: 3.0

DATE: 16-NOV-2016

Prepared By:

TATA ELXSI

CHENNAI, INDIA

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Spandana Balani	1.0	02-Jun-2015
2	Updated per design rev. 1.5.0	Rijvi Ahmed	2.0	14-Oct-2016
3	Updated per design rev. 1.7.0	TATA	3.0	16-Nov-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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

Sr. No.	Title	Version
1	MDD Guidelines	Process 04.02.01
2	Software Naming Conventions	Process 04.02.01
3	Coding standards	Process 04.02.01
4	FDD:ES247A_MotAgCmp_Design	See Synergy 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

MotAgCmpPer1

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
N/A

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes

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
MotAgCmpInit1	None	Rte (Init)

Runnable	Scheduling Requirements	Trigger
MotAgCmpPer1	None	Motor Control ISR*2
MotAgCmpPer2		RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotCtrl_START_SEC_CODE	Code section for Motor Control scheduled functions

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

*See DataDict.m

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

22.3 - MotAgCmp_MDD

Module Design Document

For

MotAgCmp

VERSION: 3.0

DATE: 16-Nov-2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

TATA ELXSI

CHENNAI, INDIA

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial Version	SB	1.0	02-JUN-2015
2	Updated per design rev. 1.5.0	Rijvi	2.0	13-OCT-2016
3	Updated per design rev. 1.7.0	TATA	3.0	16-NOV-2016

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 motagcmp & High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation of motagcmp 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.2 Initialization Functions 11

7.2.1.1 MotAgCmpInit1 11

7.2.1.2 Design Rationale 11

7.3 PERIODIC FUNCTIONS 11

7.3.1 Per: Motagcmpper1 11

7.3.1.1 Design Rationale 11

7.3.1.2 Store Module Inputs to Local copies 11

7.3.1.3 (Processing of function)……… 11

7.3.1.4 Store Local copy of outputs into Module Outputs 11

7.3.2 Per: Motagcmpper2 11

7.3.2.1 Design Rationale 11

7.3.2.2 Store Module Inputs to Local copies 11

7.3.2.3 (Processing of function)……… 11

7.3.2.4 Store Local copy of outputs into Module Outputs 11

7.4 Non PERIODIC FUNCTIONS 11

7.5 Interrupt Functions 11

7.6 Serial Communication Functions 13

7.7 SERVER RUNNABLES 13

7.7.1 MotAgCmpBackEmfRead_Oper 13

7.7.2 MotAgCmpBackEmfWr_Oper 13

7.8 Local Function/Macro Definitions 13

7.9 GLObAL Function/Macro Definitions 13

7.10 TRANSIENT FUNCTIONS 13

8 Unit Test Considerations 14

9 Known Limitations With Design 15

10 Appendix 16

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

Sr. No.	Title	Version
1	MDD Guidelines	Process 04.02.01
2	Software Naming Conventions	Process 04.02.01
3	Coding standards	2.1
4	FDD: ES247A_MotAgCmp_Design	See Synergy Subproject version

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

motagcmp & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation of motagcmp

Data Flow Diagram

Please refer FDD.

Module level DFD

Please refer FDD.

Sub-Module level DFD

Please refer FDD.

COMPONENT FLOW DIAGRAM

Please refer FDD.

Variable Data Dictionary

User defined typedef definition/declaration

Typedef Name

Element Name

User Defined Type

Legal Range

(min)

Legal Range

(max)

N/A

Variable definition for enumerated types

Enum Name	Element Name	Value
N/A	N/A	N/A

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value
Refer constants from .m file	N/A	N/A	N/A

Global

Constant Name

N/A

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
Refer .m file	N/A	N/A	N/A

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

MotAgCmpInit1

Design Rationale

None

PERIODIC FUNCTIONS

Per: Motagcmpper1

Design Rationale

None

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: Motagcmpper2

Design Rationale

None

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

Non PERIODIC FUNCTIONS

None

Interrupt Functions

None

Serial Communication Functions

None

SERVER RUNNABLES

MotAgCmpBackEmfRead_Oper

See DataDict.m file and model

MotAgCmpBackEmfWr_Oper

See DataDict.m file and model

Local Function/Macro Definitions

None

GLObAL Function/Macro Definitions

None

TRANSIENT FUNCTIONS

None

Unit Test Considerations

None

Known Limitations With Design

None

Appendix

None

23 - Component Implementation

Component Implementation

Component Documentation

23.1 - MotAgCorrln_DesignReview

Overview

Summary Sheet
Synergy Project
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES249A_MotAgCorrln_Imp

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. ES249A_MotAgCorrln_Impl_4.1.0

Change Owner:

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

Work CR ID:

EA4#5426

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

Reviewed only changes

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:

Krishna Anne

Review Date :

04/19/16

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

MotAgCorrln.c

Source File Revision:

7

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:

MotAgCorrln_MDD.docx

Revision:

5

FDD/SCIR/DSR/FDR/CM Name:

ES249A_MotAgCorrln_Design

Revision:

4.0.1

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

No changes made

for function names

N/A

Comments:

No changes made

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

No changes made

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

No changes made

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

Yes

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

boolean values are typecasted in order to cater the FDD needs

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

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

No changes made

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]

No changes made

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

No changes made

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

No changes made

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]

No changes made

All conversions between signed and unsigned

N/A

Comments:

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

No changes made

All pointer dereferencing protects against

N/A

Comments:

null pointer if needed: [N70]

No changes made

Component outputs are limited to the legal range

N/A

Comments:

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

Not required to range limit the new 3 outputs as per the FDD comment

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:

Krishna Anne

Review Date :

04/19/16

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

MotAgCorrln.c

Source File Revision:

7

Source File Name:

Source File Revision:

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Krishna Anne

Review Date :

04/19/16

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

23.2 - MotAgCorrln_Integration Manual

Integration Manual

For

‘MotAgCorrln’

VERSION: 3.0

DATE: 11 Nov 2015

Prepared By:

Software Engineering,

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

: ARM Cortex R4 Memory Usage
Sl. No.	Description	Author	Version	Date
1	Initial version	Sankardu Varadapureddi	1.0	22-May-2015
2	Modified as per latest template EA4 01.00.01 and changes performed for FDD v02.1.01	Sarika Natu	2.0	21-Aug-2015
3	Updated for v3.0.0 of FDD	Selva	3.0	11-Nov-2015

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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	FDD – ES249A_MotAgCorrln_Design	See Synergy sub project version
2	Software Naming Conventions	Process 04.2.00
3	Software Design and Coding Standards	Process 04.2.00

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
FLTINJENA	Set Value to STD_ON to enable fault injection

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file in the FDD

Required Global Data Outputs

Refer DataDict.m file in the FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotAgCorrlnInit1	None	RTE

Runnable	Scheduling Requirements	Trigger
MotAgCorrlnPer1	None	RTE (2ms)

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotAgCorrln_START_SEC_CODE

* 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>

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

23.3 - MotAgCorrln_MDD

Module Design Document

For

‘MotAgCorrln’

Apr 14,2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Krishna Anne,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Sankardu Varadapureddi	1.0	22-May-2015
Modified as per latest template EA4 01.00.01 and changes performed for FDD v02.1.01	Sarika Natu	2.0	21-Aug-2015
Updated for v 3.0.0 of the FDD	Selva Sengottaiyan	3.0	11-Nov-2015
Updated for v 3.1.0 of the FDD	Krishna Anne	4.0	19-Mar-2016
Updated for v 4.0.0 of the FDD	Krishna Anne	5.0	14-Apr-2016

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 MotAgCorrln & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of MotAgCorrln 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: MotAgCorrlnInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: MotAgCorrlnPer1 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runables 9

5.3 NoneInterrupt Functions 9

5.3.1 Interrupt Function Name 9

5.3.1.1 Design Rationale 9

5.3.1.2 (Processing of the ISR function)….. 9

5.4 Module Internal (Local) Functions 10

5.4.1 Local Function #1 10

5.4.1.1 Design Rationale 10

5.4.1.2 Processing 10

5.4.2 Local Function #2 10

5.4.2.1 Design Rationale 10

5.4.2.2 Processing 11

5.4.3 Local Function #3 11

5.4.3.1 Design Rationale 11

5.4.3.2 Processing 11

5.4.1 Local Function #2 11

5.4.1.1 Design Rationale 11

5.4.1.2 Processing 11

5.5 GLOBAL Function/Macro Definitions 12

5.5.1 GLOBAL Function #1 12

5.5.1.1 Design Rationale 12

5.5.1.2 processing 12

6 Known Limitations with Design 13

7 UNIT TEST CONSIDERATION 14

Appendix A Abbreviations and Acronyms 15

Appendix B Glossary 16

Appendix C References 17

Introduction

MDD for MotAgCorrln .

MotAgCorrln & High-Level Description

None

Design details of software module

Graphical representation of MotAgCorrln

Data Flow Diagram

Refer FDD

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
MOTAGMECLCORRLNSTMIN_CNT_U08	None	NA	0
MOTAGMECLCORRLNSTMAX_CNT_U08	None	NA	7
MOTAGMECLIDPTSIGMIN_CNT_U08	None	Cnt	0
MOTAGMECLIDPTSIGMAX_CNT_U08	None	Cnt	3

Software Component Implementation

Sub-Module Functions

Init: MotAgCorrlnInit1

Refer FDD

Design Rationale

Design follows implementation in FDD.

Module Outputs

Refer FDD

Per: MotAgCorrlnPer1

Refer FDD

Design Rationale

Refer FDD

Store Module Inputs to Local copies

Refer FDD

(Processing of function)………

Refer to FDD (Block ‘MotAgCorrlnPer1’)

Store Local copy of outputs into Module Outputs

Refer FDD

Server Runables

NoneInterrupt Functions

None

Interrupt Function Name

None

Design Rationale

None

(Processing of the ISR function)…..

None

Module Internal (Local) Functions

Local Function #1

Function Name	MtrAgSigAvlCheck	Type	Min	Max
Arguments Passed	SigRollg_Cnt_T_u08	uint8	0	255
	SigQlfr_Cnt_T_enum	Enum (SigQlfr1)	SIGQLFR_NORES	SIGQLFR_FAILD
	LstRollg_Cnt_T_u08	uint8	0	255
	LstStall_Cnt_T_u08	uint8	0	255
	*StallCntOutp_Cnt_T_u08	uint8	0	255
Return Value	SigAvl_Cnt_T_lgc	boolean	FALSE	TRUE

Design Rationale

Checks Signal Availability of Motor. Implementation of 'MtrAgA SigAvlCheck', 'MtrAgB SigAvlCheck' and 'MtrAgC SigAvlCheck' blocks.

Processing

Note: ‘* StallCntOutp_Cnt_T_u08’ is an output of this function.

Local Function #2

Function Name	TestOkCheck	Type	Min	Max
Arguments Passed	MotAgAMecl_MotRev_T_u0p16	uint16	0	65535
	MotAgBMecl_MotRev_T_u0p16	uint16	0	65535
	MotAgCMecl_MotRev_T_u0p16	uint16	0	65535
	*MotAgOkA_Cnt_T_lgc	boolean	FALSE	TRUE
	*MotAgOkB_Cnt_T_lgc	boolean	FALSE	TRUE
	*MotAgOkC_Cnt_T_lgc	boolean	FALSE	TRUE
	*MotAgABErrTerm_T_u0p16	uint16	0U	32768U
	*MotAgBCErrTerm_T_u0p16	uint16	0U	32768U
	*MotAgACErrTerm_T_u0p16	uint16	0U	32768U
Return Value	None

Design Rationale

Implementation of 'TestOk' check functionality. This function corresponds to blocks 'MotAgA vs MotAgB', 'MotAgA vs MotAgC', 'MotAgB vs MotAgC' and 'TestOk'.

Processing

‘*MotAgOkA_Cnt_T_lgc’, ‘*MotAgOkB_Cnt_T_lgc’ and ‘*MotAgOkC_Cnt_T_lgc’ are outputs of this function

Local Function #3

Function Name	MtrAgNotFailedCheck	Type	Min	Max
Arguments Passed	* MotAgANotFailed_Cnt_T_lgc	boolean	FALSE	TRUE
	* MotAgBNotFailed_Cnt_T_lgc	boolean	FALSE	TRUE
	* MotAgCNotFailed_Cnt_T_lgc	boolean	FALSE	TRUE
	* MotAgMeclIdptSig_Cnt_T_u08	uint8	0	3
	MotAgSigAvlA_Cnt_T_lgc	boolean	FALSE	TRUE
	MotAgSigAvlB_Cnt_T_lgc	boolean	FALSE	TRUE
	MotAgSigAvlC_Cnt_T_lgc	boolean	FALSE	TRUE
Return Value	None

Design Rationale

Implementation of 'NotFailed' block functionality.

MotAgANotFailed_Cnt_T_lgc, MotAgBNotFailed_Cnt_T_lgc, MotAgCNotFailed_Cnt_T_lgc and MotAgMeclIdptSig_Cnt_T_u08 are outputs of this function.

Processing

All arguments are outputs of this function

Local Function #2

Function Name	CalcErrTerm	Type	Min	Max
Arguments Passed	MotAgAMecl_MotRev_T_u0p16	uint16	0	65535
	MotAgBMecl_MotRev_T_u0p16	uint16	0	65535
	MotAgCMecl_MotRev_T_u0p16	uint16	0	65535
Return Value	ErrorTerm_Rev_T_u0p16	uint16	0	32768

Design Rationale

MotAg“X” vs MotAg“Y” where X can be A,B and Y can be B, C block, the implementation will not result in negative values as sign of Switch2 and Abs are changed. Hence Abs1 function is redundant in implementation and ignored.. (Note: Switch 2 always results in MAX VALUE of U0P16 Datatype. So Subtraction of delta from it will not result in negative value)

Processing

Delta between two input motor angle will outputs of this function

GLOBAL Function/Macro Definitions

GLOBAL Function #1

None

Design Rationale

None

processing

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description
FDD	Functional Design Document

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.02
3	Software Naming Conventions.doc	EA4 01.00.02
4	Software Design and Coding Standards.doc	EA4 01.00.02
5	ES249A_MotAgCorrln_Design	See Synergy subproject version

23.4 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
ES249A	112	MotAgCorrln.c	MotAgCorrlnPer1	924	I
ES249A	115	MotAgCorrln.c	MotAgCorrlnPer1	925	I
ES249A	102	MotAgCorrln.c	MtrAgNotFailedCheck	1174-1235	I
ES249A	111	MotAgCorrln.c	MotAgCorrlnPer1	923	I
ES249A	65	MotAgCorrln.c	MotAgCorrlnPer1	839	I
ES249A	66	MotAgCorrln.c	MotAgCorrlnPer1	841	I
ES249A	67	MotAgCorrln.c	MotAgCorrlnPer1	842	I
ES249A	68	MotAgCorrln.c	MotAgCorrlnPer1	843	I
ES249A	69	MotAgCorrln.c	MotAgCorrlnPer1	845	I
ES249A	80	MotAgCorrln.c	TestOkCheck	1047-1066	I
ES249A	87	MotAgCorrln.c	TestOkCheck	1072-1090	I
ES249A	101	MotAgCorrln.c	MtrAgNotFailedCheck	1173-1234	I
ES249A	22	MotAgCorrln.c	TestOkCheck	1016-1037	I
ES249A	49	MotAgCorrln.c	MotAgCorrlnPer1	838	I
ES249A	28	MotAgCorrln.c	TestOkCheck	1017-1038	I
ES249A	104	MotAgCorrln.c	MtrAgNotFailedCheck	1176-1237	I
ES249A	96	MotAgCorrln.c	MtrAgNotFailedCheck	1169-1230	I
ES249A	83	MotAgCorrln.c	TestOkCheck	1070-1088	I
ES249A	100	MotAgCorrln.c	MtrAgNotFailedCheck	1172-1233	I
ES249A	98	MotAgCorrln.c	MtrAgNotFailedCheck	1171-1232	I
ES249A	108	MotAgCorrln.c	TestOkCheck	1045-1064	I
ES249A	74	MotAgCorrln.c	TestOkCheck	1044-1063	I
ES249A	71	MotAgCorrln.c	MotAgCorrlnPer1	847	I
ES249A	70	MotAgCorrln.c	MotAgCorrlnPer1	846	I
ES249A	91	MotAgCorrln.c	TestOkCheck	1014-1035,1042-1061,1092-1139	I
ES249A	90	MotAgCorrln.c	MotAgCorrlnPer1	881-897	I
ES249A	93	MotAgCorrln.c	TestOkCheck	1015-1036,1068-1086,1093-1140	I
ES249A	92	MotAgCorrln.c	MtrAgNotFailedCheck	1168-1180	I
ES249A	95	MotAgCorrln.c	TestOkCheck	1043-1062,1069-1087,1094-1141	I
ES249A	107	MotAgCorrln.c	TestOkCheck	1018-1039	I
ES249A	97	MotAgCorrln.c	MtrAgNotFailedCheck	1170-1231	I
ES249A	78	MotAgCorrln.c	TestOkCheck	1046-1065	I
ES249A	48	MotAgCorrln.c	MotAgCorrlnPer1	837	I
ES249A	31	MotAgCorrln.c	TestOkCheck	1019-1040	I
ES249A	51	MotAgCorrln.c	MotAgCorrlnPer1	921	I
ES249A	53	MotAgCorrln.c	MotAgCorrlnPer1	849-865	I
ES249A	52	MotAgCorrln.c	MotAgCorrlnPer1	922	I
ES249A	109	MotAgCorrln.c	TestOkCheck	1071-1089	I
ES249A	103	MotAgCorrln.c	MtrAgNotFailedCheck	1175-1236	I
ES249A	110	MotAgCorrln.c	MotAgCorrlnPer1	901-910	I

24 - Component Implementation

Component Implementation

Component Documentation

24.1 - MotAgSwCal_IntegrationManual

Integration Manual

For

MotAgSwCal

VERSION: 1.0

DATE: 23-AUG-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.#	Description	Author	Version	Date
1	Initial version	Shruthi Raghavan	1.0	23-Aug-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	Integration Manual Template	1.3
2	Software Naming Conventions	1.0
3	Coding standards	2.1
4	FDD	See Synergy subproject version

Dependencies

SWCs

Module	Required Feature
None	-

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

MotAgSwCalPer1

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
Nonw

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotAgSwCalInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
MotAgSwCalPer1	None	ISR(MotCtrlRate)
MotAgSwCalPer2	None	RTE(10ms)
SwCalStrt	None	On invocation
SwCalStop	None	On invocation
SwCalGetPrm	None	On invocation
SwCalSetPrm	None	On invocation

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotCtrl_START_SEC_CODE^†
CDD_MotAgSwCal_START_SEC_CODE

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

† MotAgSwCal_MotCtrl_START_SEC_CODE is refined to this in CDD_MotAgSwCal_MotCtrl_MemMap.h

Usage

Feature	RAM	ROM
N/A

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

MfgEnaSt1 enumeration must be defined by AR300A in configurator.

24.2 - MotAgSwCal_MDD

Module Design Document

For

MotAgSwCal

23-AUG-2017

Prepared By:

Shruthi Raghavan,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Shruthi Raghavan	1.0	15-Jul-2015

Table of Contents

1 Introduction 2

1.1 Purpose 2

1.2 Scope 2

2 <Component Name> & High-Level Description 2

3 Design details of software module 2

3.1 Graphical representation of <Component Name> 2

3.2 Data Flow Diagram 2

3.2.1 Component level DFD 2

3.2.2 Function level DFD 2

4 Constant Data Dictionary 2

4.1 Program (fixed) Constants 2

4.1.1 Embedded Constants 2

5 Software Component Implementation 2

5.1 Sub-Module Functions 2

5.1.1 Init: <ModuleName>Init<n> 2

5.1.1.1 Design Rationale 2

5.1.1.2 Module Outputs 2

5.1.2 Per: <ModuleName>_Per<n> 2

5.1.2.1 Design Rationale 2

5.1.2.2 Store Module Inputs to Local copies 2

5.1.2.3 (Processing of function)……… 2

5.1.2.4 Store Local copy of outputs into Module Outputs 2

5.2 Server Runables 2

5.2.1 <Server Runable Name> 2

5.2.1.1 Design Rationale 2

5.2.1.2 (Processing of function)……… 2

5.3 Interrupt Functions 2

5.3.1 Interrupt Function Name 2

5.3.1.1 Design Rationale 2

5.3.1.2 (Processing of the ISR function)….. 2

5.4 Module Internal (Local) Functions 2

5.4.1 Local Function #1 2

5.4.1.1 Design Rationale 2

5.4.1.2 Processing 2

5.5 GLOBAL Function/Macro Definitions 2

5.5.1 GLOBAL Function #1 2

5.5.1.1 Design Rationale 2

5.5.1.2 processing 2

6 Known Limitations with Design 2

7 UNIT TEST CONSIDERATION 2

Appendix A Abbreviations and Acronyms 2

Appendix B Glossary 2

Appendix C References 2

Introduction

Purpose

Module design document for MotAgSwCal component.

MotAgSwCal & High-Level Description

This component is used to determine the calibration parameters of the hall sensor based on motor angle data samples. A modulation index profile is fenerated based on process parameters and average motor angle is calculated and sent out using a client call when the data is ready.

Design details of software module

Graphical representation of MotAgSwCal

Data Flow Diagram

Component level DFD

Refer FDD Simulink Model

Function level DFD

Refer FDD Simulink Model

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
POSNSTEPSIZEDFT_MOTREVELEC_U0P16	P16	MotRevElec	FloatToFixd_u16_f32(0.031250477F,NXTRFIXDPT_FLOATTOP16_ULS_F32)
PSBLNROFMOTAGMEAS_CNT_U08	1	Cnt	6U
PSBLNROFSINCOSCPT_CNT_U08	1	Cnt	PSBLNROFMOTAGMEAS_CNT_U08*2

Software Component Implementation

Sub-Module Functions

Init: MotAgSwCalInit1

Design Rationale

None.

Per: MotAgSwCalPer1

Design Rationale

None

Per: MotAgSwCalPer2

Design Rationale

None

Server Runables

SwCalGetPrm

Design Rationale

None

SwCalSetPrm

Design Rationale

None

SwCalStop

Design Rationale

None

SwCalStrt

Design Rationale

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	RstFctPrm	Type	Min	Max
Arguments Passed	None	-	-	-
Return Value	N/A	-	-	-

Design Rationale

None.

Local Function #2

Function Name	CalcMotAgDelta	Type	Min	Max
Arguments Passed	CurrMotAgCptVal_Volt_T_f32	Float32	0.0F	5.0F
	* PrevMotAgCptVal_Cnt_T_u16	U3p13	0.0F	7.99987792F
Return Value	MotAgDelta_Cnt_T_u16	Uint16	0U	65535U

Design Rationale

None.

Local Function #3

Function Name	UpdFaildAdcCntrs	Type	Min	Max
Arguments Passed	None	-	-	-
Return Value	N/A	-	-	-

Design Rationale

None.

Local Function #4

Function Name	UpdTiOuts	Type	Min	Max
Arguments Passed	None	-	-	-
Return Value	N/A	-	-	-

Design Rationale

None.

GLOBAL Function/Macro Definitions

GLOBAL Function #1

Function Name	-	Type	Min	Max
Arguments Passed	-	-	-	-
Return Value	-	-	-	-

Design Rationale

N/A

Known Limitations with Design

See Continuous Improvement CR EA4#15533

UNIT TEST CONSIDERATION

Intentional rollovers and cast overflows are explicitly indicated in the code.

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1

24.3 - MotAgSwCal_PeerReviewChecklist

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-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. MotAgSwCal

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. ES280A_MotAgSwCal_Impl_2.0.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. Shruthi Raghavan

Work CR ID:

EA4#12616

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci 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:

Shruthi Raghavan

Review Date :

09/22/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

N/A

Comments:

versions (If available)

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

Initial Version

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

Arguments to server runnables are too many - make into structure: Waiting on FDD. : 9/22 baseline without these changes. Design rejected the change proposal.

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:

Shruthi Raghavan

Review Date :

09/22/17

Component Type :

CDD

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAgSwCal.c

Source File Revision:

1

Header File Name:

CDD_MotAgSwCal_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. 1

MDD Name:

MotAgSwCal_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

ES280A_MotAgSwCal_Design

Revision:

2.1.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

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.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

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

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

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.

Yes

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:

Add function header for UpdTiOuts : Done 9/22/2017

Model

1. Change constant to STRT rather than START : Done in 9/22/2017 FDD baseline

2. Change limits on slew pims to lower limit being 0 : Done in 9/22/2017 FDD baseline

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:

Shruthi Raghavan

Review Date :

09/22/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Raghavendran Mohan

Sheet 5: Source Code1

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotAgSwCal_MotCtrl.c

Source File Revision:

1

Header File Name:

CDD_MotAgSwCal.h

Header File Revision:

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

Header File Name:

CDD_MotAgSwCal_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. 1

MDD Name:

MotAgSwCal_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

ES280A_MotAgSwCal_Design

Revision:

2.1.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

Global in/outs are assumed to be initialized to 0

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

Yes

Comments:

is per standard

All execution-order-dependent code can be

N/A

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

Yes

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

Comments:

including all use of fixed point macros and

some overflows are intentional and are indicated as such

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsiged conversions ensure the.

Yes

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

Yes

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

Yes

Comments:

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

All code is mapped with FDD (all FDD

Yes

Comments:

subfunctions and/or model blocks identified

with code comments; all code corresponds to

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

Review did not identify violations of other

Yes

Comments:

coding standard rules

Anomaly or Design Work CR created

Yes

Comments: List Anomaly or CR numbers

for any FDD corrections needed

EA4#15533

General Notes / Comments:

SamplePosnIdx pim needs to be updated somewhere in Per1 of MotCtrl file: check code is missing a line from model : Done 9/22/2017

SampleProcdFlg output might not be necessary from Per2 so the input flag to MotCtrl is not necessary : Replaced the RTE in/outs with the PIM 9/22/2017

Limits on the rolling counter pims for adc failures is unnecessary : Done 9/22/2017

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:

Shruthi Raghavan

Review Date :

09/22/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Raghavendran Mohan

Sheet 6: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

MotAgSwCal_MDD.docx

MDD Revision:

1

Source File Name:

CDD_MotAgSwCal.c

Source File Revision:

1

Source File Name:

CDD_MotAgSwCal_MotCtrl.c

Source File Revision:

1

Source File Name:

CDD_MotAgSwCal_private.c

Source File Revision:

1

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)

N/A

Comments:

Initial Version

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

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:

Shruthi Raghavan

Review Date :

09/22/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_MotAgSwCal.c

Source File Revision:

1

Source File Name:

CDD_MotAgSwCal_MotCtrl.c

Source File Revision:

1

Source File Name:

CDD_MotAgSwCal_private.c

Source File Revision:

1

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

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

See comments below*

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

In Rte_Stubs.c , Rte_Call_CDD_MotAgSwCal_SwCalStsCallBack_Oper definition is changed by making the right hand side of the assignment inside the for loop to be SnsrData_Ary1D[i] instead of (*SnsrData_Ary1D)[i]

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:

Review Date :

Lead Peer Reviewer:

Approved by Reviewer(s):

Other Reviewer(s):

Sheet 8: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

Initial Version

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:

Shruthi Raghavan

Review Date :

09/22/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

25 - Component Implementation

Component Implementation

Component Documentation

25.1 - ES006A_NvM_Integration_Manual

Integration Manual

For

ES006A NvM

VERSION: 4

DATE: 07-Jul-2017

Prepared By:

Kevin Smith

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	Approved By
1	Initial version	K. Smith	1.0	28-Jan-16	-
2	Updates for fast ignition cycles	O. Tosh	2	27-Jun-16	-
3	Updates for Naming Convections	K. Smith	3	28-Sep-16	-
4	Update to the appendix for required NvM block name	K. Smith	4	07-Jul-17

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 7

4.5 Manual Configuration Changes 7

4.6 Exclusive Area Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	Process 04.02.00
2	Software Naming Conventions	Process 04.02.00
3	Coding standards	Process 04.02.00
4	ES006A_NvM_Design	See Synergy subproject version

Dependencies

SWCs

Module	Required Feature
None

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

NvMProxy_Init0()

NvMProxy_MainFunction()

NvMProxy_ClsChkWr_Oper()

NvMProxy_MultiBlkCallBack()

NvM Proxy API Functions

NvMProxy_EraseNvBlock()

NvMProxy_GetDataIndex()

NvMProxy_GetErrorStatus()

NvMProxy_InvalidateNvBlock()

NvMProxy_ReadBlock()

NvMProxy_RestoreBlockDefaults()

NvMProxy_SetBlockProtection()

NvMProxy_SetDataIndex()

NvMProxy_SetRamBlockStatus()

NvMProxy_WriteBlock()

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

CDD_NvM_Cfg_private.h
CDD_NvMProxy_Cfg.h
CDD_NvMProxy_Cfg.c
CDD_NvMProxy_Cbk.h
CDD_NvMProxy_Cbk.c
CDD_NvMProxyDftDataGroup.h
NvMProxy_swc_arxml (service component to be imported into Developer)

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
/Nexteer/EcucDefs_SyncCrc/NvMProxy/NvMProxyCommon/NvMOsApplicationRef	This shall point to the application that the NvM component is integrated. Typically this is an ASIL D application.	NvMProxy
/Nexteer/EcucDefs_SyncCrc/NvMProxy/NvMProxyCommon/NvmProxyIncludes	Additional includes for callback functions if required.	NvMProxy
//Nexteer/EcucDefs_NvMProxy/NvMProxy/NvMProxyBlkSet/NvMBlkRef	Reference to the NvM block that NvMProxy will check	NvMProxy
/Nexteer/EcucDefs_NvMProxy/NvMProxy/NvMProxyBlkSet/NvMBlkFlt	This shall be set to the NTC that a failed NvMProxy check is required to set (NTC 6,7,8 or A)	NvMProxy
/Nexteer/EcucDefs_NvMProxy/NvMProxy/NvMProxyBlkSet/NvMProxyApplCallCbk	If a NvM block requires a callback function, this field shall be populated with the function name. The function prototype can be included by a header file defined in the NvMProxyIncludes section.	NvMProxy
/ActiveEcuC/NvM/NvMCommon/NvMMultiBlockCallback	Shall be set to NvMProxy_MultiBlkCallBack.	NvM

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Exclusive Area Changes

Name	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Required Global Data Outputs

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
NvMProxyInit1	Shall be called after DiagcMgr has been initazlied	RTE Init
NvMProxyCrcInit0	Shall be scheduled outside of the RTE after NvM_ReadAll()	Non-RTE Init

Runnable	Scheduling Requirements	Trigger
None	None	N/A

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

*See DataDict.m

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

Quick Ignition Cycles

To ensure proper handling for quick ignition cycles, the integration team must call NvMProxy_MultiBlkCallBack manually prior to calling NvM_WriteAll(). Ideally this should be placed within the same BswM call as the NvM_WriteAll().

The call should implemented similary as shown below:

NvMProxy_MultiBlkCallBack(NVM_WRITE_ALL, NVM_REQ_PENDING);

NvM_WriteAll()

This will record all the NvM block status into the PIM. Once the WriteAll has completed or has been canceled by the NvM_CancelWriteAll() or NvM_KillWriteAll(), the NvM shall call the callback function and restore the RAM statuses back to their values prior to the NvM_WriteAll() call.

NvM Block Name

The NvM block for the close check block need (ShtdwnClsChkBlk) shall be “Rte_NvmBlock_CDD_NvMProxy_ShtdwnClsChk”. This is so the generator will genearate the name that is used in the source code to call the block write outside of the RTE.

25.2 - NvMProxy Review

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
Integration Manual

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES006A_NvM_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. 1.5.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. Kevin Smith

Work CR ID:

EA4#11819

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:

No

MDD

Yes

Source Code

No

PolySpace

Yes

Integration Manual

Yes

Davinci Files

Comments:

Reviewed only the changes

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:

K. Smith

Review Date :

07/07/17

Lead Peer Reviewer:

L. Wendling

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

K. Smith

Review Date :

07/07/17

Component Type :

CDD

Lead Peer Reviewer:

L. Wendling

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_NvMProxyApi.c, CDD_NvMProxyNonRtec.

Source File Revision:

3, 4

Header File Name:

CDD_NvMProxy.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. 3

MDD Name:

N/A

Revision:

FDD/SCIR/DSR/FDR/CM Name:

ES006_NvM_Design

Revision:

1.1.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

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

Yes

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

Yes

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

Yes

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

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.

Yes

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

Yes

Comments:

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

All pointer dereferencing protects against

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

Yes

Comments:

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

All code is mapped with FDD (all FDD

Yes

Comments:

subfunctions and/or model blocks identified

with code comments; all code corresponds to

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

Review did not identify violations of other

Yes

Comments:

coding standard rules

Anomaly or Design Work CR created

Yes

Comments: List Anomaly or CR numbers

for any FDD corrections needed

General Notes / Comments:

Changes reflect what was required to get global B up and running. These have been tested locally within the integration project for some time.

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:

K. Smith

Review Date :

07/07/17

Lead Peer Reviewer:

L. Wendling

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

Yes

Comments:

General Notes / Comments:

Updated with NvM block required name.

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:

K. Smith

Review Date :

07/07/17

Lead Peer Reviewer:

L. Wendling

Approved by Reviewer(s):

Yes

Other Reviewer(s):

26 - Component Implementation

Component Implementation

Component Documentation

26.1 - PolarityCfg_Integration Manual

Integration Manual

For

‘PolarityCfg’

VERSION: 1.0

DATE: 26-May-2015

Prepared By:

Sankardu Varadapureddi,

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Sankardu Varadapureddi	1.0	26-May-2015

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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	FDD – ES102A_PolarityCfg_Design	See Synergy sub project version
2	Software Naming Conventions	Process 3.06.00
3	Software Design and Coding Standards	Process 3.06.00

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file in the FDD

Required Global Data Outputs

Refer DataDict.m file file in the FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
PolarityCfgInit1	None	Init

PolarityCfgRead_Oper

PolarityCfgWr_Oper

On event

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

* 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

Non RTE NvM Blocks

Block Name
None

RTE NvM Blocks

Block Name
PolarityCfgSaved

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None

Appendix

None

26.2 - PolarityCfg_MDD

Module Design Document

For

‘PolarityCfg’

VERSION: 3.0

DATE: 07-Jul-2017

Prepared By:

Shawn Penning,

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	Sankardu Varadapureddi	1.0	26-May-2015
3	Corrections to Name and Graphic, Update MDD Layout	Shawn Penning	3.0	07-Jul-2017

Table of Contents

1 Polarity Configuration High-Level Description 6

2 Design details of software module 7

2.1 Graphical representation of Polarity Configuration 7

2.2 Data Flow Diagram 7

2.2.1 Module level DFD 7

2.2.2 Sub-Module level DFD 7

2.3 COMPONENT FLOW DIAGRAM 8

3 Variable Data Dictionary 9

3.1 User defined typedef definition/declaration 9

3.2 Variable definition for enumerated types 9

4 Constant Data Dictionary 10

4.1 Program(fixed) Constants 10

4.1.1 Embedded Constants 10

4.1.1.1 Local 10

4.1.1.2 Global 10

4.1.2 Module specific Lookup Tables Constants 10

5 Software Module Implementation 11

5.1 Sub-Module Functions 11

5.1.1 Initialization Functions 11

5.1.1.1 INIT: PolarityCfgInit 11

5.1.1.1.1 Design Rationale 11

5.1.1.1.2 Module Outputs 11

5.1.1.1.3 Module Internal 11

5.1.2 PERIODIC FUNCTIONS 11

5.1.3 Interrupt Functions 11

5.1.4 Server runnables 12

5.1.4.1 PolarityCfgRead 12

5.1.4.1.1 Design Rationale 12

5.1.4.1.2 Store Module Inputs to Local copies 12

5.1.4.1.3 (Processing of function)……… 12

5.1.4.1.4 Store Local copy of outputs into Module Outputs 12

5.1.4.2 PolarityCfgWr 12

5.1.4.2.1 Design Rationale 12

5.1.4.2.2 Store Module Inputs to Local copies 12

5.1.4.2.3 (Processing of function)……… 12

5.1.4.2.4 Store Local copy of outputs into Module Outputs 12

5.1.5 Local Function/Macro Definitions 12

5.1.5.1 Local Function #1 12

5.1.5.2 Description 12

5.1.6 GLObAL Function/Macro Definitions 13

5.1.7 Transition FUNCTIONS 13

6 Known Limitations With Design 14

7 UNIT TEST CONSIDERATION 15

Appendix A Abbreviations and Acronyms 16

Appendix B Glossary 17

Appendix C References 18

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

Polarity Configuration High-Level Description

This function will identify polarity control settings for certain points in the design.

Design details of software module

Graphical representation of Polarity Configuration

Data Flow Diagram

Refer FDD

Module level DFD

Refer FDD

Sub-Module level DFD

Refer FDD

COMPONENT FLOW DIAGRAM

Refer FDD

Variable Data Dictionary

User defined typedef definition/declaration

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

None

Variable definition for enumerated types

Enum Name	Element Name	Value
None

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value
HWAG0POL_CNT_U32	Bitfield Mask	NA	0x00000001U
HWAG1POL_CNT_U32	Bitfield Mask	NA	0x00000002U
HWAG2POL_CNT_U32	Bitfield Mask	NA	0x00000004U
HWAG3POL_CNT_U32	Bitfield Mask	NA	0x00000008U
HWAG4POL_CNT_U32	Bitfield Mask	NA	0x00000010U
HWAG5POL_CNT_U32	Bitfield Mask	NA	0x00000020U
HWAG6POL_CNT_U32	Bitfield Mask	NA	0x00000040U
HWAG7POL_CNT_U32	Bitfield Mask	NA	0x00000080U
HWTQ0POL_CNT_U32	Bitfield Mask	NA	0x00000100U
HWTQ1POL_CNT_U32	Bitfield Mask	NA	0x00000200U
HWTQ2POL_CNT_U32	Bitfield Mask	NA	0x00000400U
HWTQ3POL_CNT_U32	Bitfield Mask	NA	0x00000800U
HWTQ4POL_CNT_U32	Bitfield Mask	NA	0x00001000U
HWTQ5POL_CNT_U32	Bitfield Mask	NA	0x00002000U
HWTQ6POL_CNT_U32	Bitfield Mask	NA	0x00004000U
HWTQ7POL_CNT_U32	Bitfield Mask	NA	0x00008000U
MOTAGMECL0POL_CNT_U32	Bitfield Mask	NA	0x00010000U
MOTAGMECL1POL_CNT_U32	Bitfield Mask	NA	0x00020000U
MOTAGMECL2POL_CNT_U32	Bitfield Mask	NA	0x00040000U
MOTAGMECL3POL_CNT_U32	Bitfield Mask	NA	0x00080000U
MOTAGMECL4POL_CNT_U32	Bitfield Mask	NA	0x00100000U
MOTAGMECL5POL_CNT_U32	Bitfield Mask	NA	0x00200000U
MOTAGMECL6POL_CNT_U32	Bitfield Mask	NA	0x00400000U
MOTAGMECL7POL_CNT_U32	Bitfield Mask	NA	0x00800000U
MOTELECMECLPOL_CNT_U32	Bitfield Mask	NA	0x01000000U
ASSIMECHPOL_CNT_U32	Bitfield Mask	NA	0x02000000U

Global

Constant Name

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
None

Software Module Implementation

Sub-Module Functions

Initialization Functions

PolarityCfgInit

INIT: PolarityCfgInit

Design Rationale

Design follows implemenetation in FDD.

Module Outputs

Refer ‘PolarityCfgInit’ block in FDD

Module Internal

None

PERIODIC FUNCTIONS

None

Interrupt Functions

None

Server runnables

PolarityCfgRead

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Refer ‘PolarityCfgRead’ block in FDD

Store Local copy of outputs into Module Outputs

None

PolarityCfgWr

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Refer ‘PolarityCfgWr’ block in FDD

Store Local copy of outputs into Module Outputs

None

Local Function/Macro Definitions

Local Function #1

Function Name	GetPolarity	Type	Min	Max
Arguments Passed	Polarity_Cnt_T_u32	uint32	0	0xFFFFFFFF
	PolarityMask_Cnt_T_u32	uint32	0x00000001	0x02000000
Return Value	Polarity_Cnt_T_s08	sint08	-1	1

Description

Design:

if ( (Polarity_Cnt_T_u32 & PolarityMask_Cnt_T_u32) == PolarityMask_Cnt_T_u32 )

set ‘Polarity_Cnt_T_s08’ to ‘1’

else

set ‘Polarity_Cnt_T_s08’ to ‘-1’

Note: ‘PolarityMask_Cnt_T_u32’ is a bit field mask and takes values mentioned in table at sec 6.1.1.1

GLObAL Function/Macro Definitions

None

Transition FUNCTIONS

None

Known Limitations With Design

None

UNIT TEST CONSIDERATION

None

Appendix A Abbreviations and Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional Design Document

Appendix B Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

Appendix C References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions.doc	EA4 01.00.00
4	Software Design and Coding Standards.doc	2.1
5	FDD : ES102A_PolarityCfg_Design	See Synergy sub project version

26.3 - PolarityCfg_Peer Review Checklists

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES102A_PolarityCfg_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. ES102A_PolarityCfg_Impl_1.1.0

Change Owner:

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

Work CR ID:

EA4#11049

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci 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:

Shawn Penning

Review Date :

07/07/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Bri Spencer

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

N/A

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Shawn Penning

Review Date :

07/07/17

Component Type :

Application

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Bri Spencer

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

PolarityCfg.c

Source File Revision:

3

Header File Name:

N/A

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

MDD Name:

PolarityCfg_MDD.docx

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

ES102A_PolarityCfg_Design

Revision:

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

Yes

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

Tags removed

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)

N/A

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

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

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

N/A

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

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

N/A

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:

Shawn Penning

Review Date :

07/07/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Bri Spencer

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

PolarityCfg_MDD.docx

MDD Revision:

3

Source File Name:

PolarityCfg.c

Source File Revision:

3

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Shawn Penning

Review Date :

07/07/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Bri Spencer

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

PolarityCfg.c

Source File Revision:

3

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.02.00

Poly Space version:

Windows User: eg. 2013b 2013B

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0

QAC version:

Windows User: eg 8.1.1-R

QAC sub project version:

Windows User: eg. TL_100A_1.1.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 Analysis

Yes

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

N/A

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

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:

Shawn Penning

Review Date :

07/07/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Bri Spencer

27 - Component Implementation

Component Implementation

Component Documentation

27.1 - PwrDiscnct_IntegrationManual

Integration Manual

For

PwrDiscnct

VERSION: 1.0

DATE: 20-Jul-2017

Prepared By:

Krishna Anne,

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.	Description	Author	Version	Date
1	Initial version	Krishna Anne	1.0	20-Jul-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional 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	FDD – ES003C PwrDiscnct	See Synergy subproject version
2	Software Naming Conventions	Process 04.02.00
3	Software Coding Standards	Process 04.02.00

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file

Required Global Data Outputs

Refer DataDict.m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
PwrDiscnctInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
PwrDiscnctPer1	None	RTE (2 ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None.

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None.

27.2 - PwrDiscnct_MDD

Module Design Document

For

PwrDiscnct

JulAug 204, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Krishna Anne

Software Group,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	Krishna Anne	1.0	20-Jul-2017
Range of NTC042ParmByte_Cnt_T_u08 is changed in local functions	Krishna Anne	2.0	04-Aug-2017

Table of Contents

1 Introduction 5

1.1 Purpose 5

2 HwTq0Meas & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of HwTq0Meas 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: HwTq0MeasInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: HwTq0MeasPer1 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.1.3 Per: HwTq0MeasPer2 9

5.1.3.1 Design Rationale 9

5.1.3.2 Store Module Inputs to Local copies 10

5.1.3.3 (Processing of function)……… 10

5.1.3.4 Store Local copy of outputs into Module Outputs 10

5.2 Server Runables 10

5.2.1 HwTq0MeasHwTq0AutTrim_oper 10

5.2.1.1 Design Rationale 10

5.2.1.2 (Processing of function)……… 10

5.2.2 HwTq0MeasHwTq0ClrTrim_Oper 10

5.2.2.1 Design Rationale 10

5.2.2.2 (Processing of function)……… 10

5.2.3 HwTq0MeasHwTq0ReadTrim_Oper 10

5.2.3.1 Design Rationale 10

5.2.3.2 (Processing of function)……… 10

5.2.4 HwTq0MeasHwTq0TrimPrfmdSts_Oper 11

5.2.4.1 Design Rationale 11

5.2.4.2 (Processing of function)……… 11

5.2.5 HwTq0MeasHwTq0WrTrim_Oper 11

5.2.5.1 Design Rationale 11

5.2.5.2 (Processing of function)……… 11

5.2.6 HwTq0MeasTrigStrt_Oper 11

5.2.6.1 Design Rationale 11

5.2.6.2 (Processing of function)……… 11

5.3 Interrupt Functions 11

5.4 Module Internal (Local) Functions 11

5.4.1 Local Function #1 11

5.4.1.1 Design Rationale 11

5.4.2 Local Function #2 12

5.4.2.1 Design Rationale 12

5.5 GLOBAL Function/Macro Definitions 12

6 Known Limitations with Design 13

7 UNIT TEST CONSIDERATION 14

Appendix A Abbreviations and Acronyms 15

Appendix B Glossary 16

Appendix C References 18

Introduction

Purpose

Module design document for PwrDiscnct.

HwTq0Meas & High-Level Description

Design details of software module

Graphical representation of HwTq0Meas

Data Flow Diagram

Component level DFD

N/A

Function level DFD

N/A

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
TESTNORES_CNT_U08	1	Cnt	0U
TESTPASSD_CNT_U08	1	Cnt	1U
TESTFAILD_CNT_U08	1	Cnt	2U

Note : These local constants are used in place of SIGQLFR_NORES (0U), SIGQLFR_PASSD (1U) and SIGQLFR_FAILD (2U) that are used by FDD because the datatype SigQlfr1 is not necessary for this purpose as well as it not possible to get them defined from RTE when no client call that uses this datatype as one of its arguments is defined by current design.

Software Component Implementation

Sub-Module Functions

Init: HwTq0MeasInit1

Design Rationale

Module Outputs

Refer to FDD

Per: HwTq0MeasPer1

Design Rationale

None

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

Server Runables

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	VerifyDiscOpen	Type	Min	Max
Arguments Passed	BattVltg_Volt_T_f32	float32	0.0F	40.0F
	BattVltgSwd1_Volt_T_f32	float32	0.0F	40.0F
	*NTC042ParmByte_Cnt_T_u08	uint08	0U	55U
	PwrDiscnctSwtDiag_Volt_T_f32	float32	0.0F	40.0F
	ChrgPmpDiag_Volt_T_f32	float32	0.0F	40.0F
	MotVelMrf_MotRadPerSec_T_f32	float32	-1350.0F	1350.0F
	*ErrAccOutp_Cnt_T_u16	uint16	0U	65535U
Return Value	N/A	N/A	N/A	N/A

Design Rationale

Path in FDD : ES003C_PwrDiscnct/PwrDiscnct/PwrDiscnctPer1/WarmInit/Operate/OPEN&CLOSE/VERIFYDISCOPEN.

Local Function #2

Function Name	VerifyClose	Type	Min	Max
Arguments Passed	BattVltg_Volt_T_f32	float32	0.0F	40.0F
	BattVltgSwd1_Volt_T_f32	float32	0.0F	40.0F
	*NTC042ParmByte_Cnt_T_u08	uint08	0U	55U
	PwrDiscnctSwtDiag_Volt_T_f32	float32	0.0F	40.0F
	*ErrAccOutp_Cnt_T_u16	uint16	0U	65535U
Return Value	N/A	N/A	N/A	N/A

Design Rationale

Path in FDD : ES003C_PwrDiscnct/PwrDiscnct/PwrDiscnctPer1/WarmInit/Operate/OPEN&CLOSE/VERIFYCLOSE.

Local Function #3

Function Name	InitialDiag	Type	Min	Max
Arguments Passed	BattVltg_Volt_T_f32	float32	0.0F	40.0F
	BattVltgSwd1_Volt_T_f32	float32	0.0F	40.0F
	*NTC042ParmByte_Cnt_T_u08	uint08	0U	55U
	PwrDiscnctSwtDiag_Volt_T_f32	float32	0.0F	40.0F
	ChrgPmpDiag_Volt_T_f32	float32	0.0F	40.0F
Return Value	N/A	N/A	N/A	N/A

Design Rationale

Path in FDD : ES003C_PwrDiscnct/PwrDiscnct/PwrDiscnctPer1/WarmInit/Operate/OPEN&CLOSE/VERIFYDISCOPEN/InitialDiag.

Local Function #4

Function Name	PwrDiscnctDiag	Type	Min	Max
Arguments Passed	BattVltg_Volt_T_f32	float32	0.0F	40.0F
	ChrgMinDelta_Volt_T_f32	float32	0.0F	40.0F
	BattVltgAdcFaild_Cnt_T_logl	boolean	FALSE	TRUE
	ChrgPmpDiagAdcFaild_Cnt_T_logl	boolean	FALSE	TRUE
	ChrgPmpDiag_Volt_T_f32	float32	0.0F	40.0F
Return Value	N/A	N/A	N/A	N/A

Design Rationale

Path in FDD : Path in FDD : ES003C_PwrDiscnct/PwrDiscnct/PwrDiscnctPer1/WarmInit/Operate/RUNTIMEDIAG/PwrDiscnctDiagnostic.

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

Please see not in section 4.1.1.1 w.r.t SigQlfr1 enumeration’s non-usage.

UNIT TEST CONSIDERATION

Please see not in section 4.1.1.1 w.r.t SigQlfr1 enumeration’s non-usage.

Abbreviations and Acronyms

Abbreviation or Acronym	Description
DFD	Design functional diagram
MDD	Module design Document

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES003C PwrDiscnct	See Synergy subproject version

27.3 - PwrDiscnct_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES003C_PwrDiscnct_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. ES003C_PwrDiscnct_Impl_1.2.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. Krishna Anne

Work CR ID:

EA4#14463

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci 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:

Krishna Anne

Review Date :

08/07/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

N/A

Comments:

For components not using application data types, do all

N/A

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

N/A

Comments:

versions (If available)

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

Initial version

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

N/A

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

No display variables available

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Krishna Anne

Review Date :

08/07/17

Component Type :

Application

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

PwrDiscnct.c

Source File Revision:

3

Header File Name:

NA

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

MDD Name:

PwrDiscnct_MDD.doc

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES003C_PwrDiscnct_Design

Revision:

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

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

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

N/A

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

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]

Boolean outputs

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:

Local constantsTESTNORES_CNT_U08, TESTPASSD_CNT_U08 and TESTFAILD_CNT_U08 are respectively used in place of SIGQLFR_NORES (0U), SIGQLFR_PASSD (1U) and SIGQLFR_FAILD (2U) that are used by FDD because the datatype SigQlfr1 is not necessary for this purpose as well as it is not possible to get them defined from RTE when no client call that uses this datatype as one of its arguments is defined in Davinci developer.

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:

Krishna Anne

Review Date :

08/07/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

PwrDiscnct.c

Source File Revision:

3

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 NA

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Initial version

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Krishna Anne

Review Date :

08/07/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

28 - Component Implementation

Component Implementation

Component Documentation

28.1 - PwrSply_IntegrationManual

Integration Manual

For

PwrSply

VERSION: 3.0

DATE: 20-Mar-2017

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.	Description	Author	Version	Date
1	Initial version	Rijvi Ahmed	1.0	15-Sep-2015
2	Updated per design rev. 1.4.0	Rijvi Ahmed	2.0	04_April-2016
3	Updated per design rev. 1.7.0	Krishna Anne	3.0	20-Mar-17

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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional 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	FDD – ES008A PwrSply	See Synergy subproject version
2	Software Naming Conventions	Process 04.02.01
3	Software Coding Standards	Process 04.02.01

Dependencies

SWCs

Module	Required Feature
Spi_Renesas_Ar4.0.3_01.06.05_HF	Refer CM600A_CSIG0CfgAndUse_Design
CM600A_CSIG0CfgAndUse_Design	Channel and Sequence definitions and API requirements.

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
See CM600A_CSIG0CfgAndUse_Design requirements.

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file

Required Global Data Outputs

Refer DataDict.m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
PwrSplyInit1	None	RTE/Init

Runnable	Scheduling Requirements	Trigger
PwrSplyPer1	None	RTE ( 4ms )

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

28.2 - PwrSply_MDD

Module Design Document

For

PwrSply

Mar 20, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	Rijvi Ahmed	1.0	15-Sep-2015
Updated per design rev. 1.4.0	Rijvi Ahmed	2.0	04-April-2016
Updated per design rev. 1.7.0	Krishna Anne	3.0	20-Mar-17

Table of Contents

1 Introduction 4

2 PwrSply & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of PwrSply 6

3.2 Data Flow Diagram 6

3.2.1 Component level DFD 6

3.2.2 Function level DFD 6

4 Constant Data Dictionary 7

4.1 Program (fixed) Constants 7

4.1.1 Embedded Constants 7

5 Software Component Implementation 8

5.1 Sub-Module Functions 8

5.1.1 Init: PwrSplyInit1 8

5.1.1.1 Design Rationale 8

5.1.1.2 (Processing of function)……… 8

5.1.2 Per: PwrSplyPer1 8

5.1.2.1 Design Rationale 8

5.1.2.2 Store Module Inputs to Local copies 8

5.1.2.3 (Processing of function)……… 8

5.1.2.4 Store Local copy of outputs into Module Outputs 8

5.2 Server Runnable 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 10

7 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 15

Introduction

None

PwrSply & High-Level Description

None

Design details of software module

<The Data Flow Diagrams should be created in the absence of this representation with the FDD.>

Graphical representation of PwrSply

Data Flow Diagram

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Refer to the DataDictionary of the design

Software Component Implementation

Sub-Module Functions

The sub-module functions are grouped based on similar functionality that needs to be executed in a given “State” of the system (refer States and Modes). For a given module, the MDD will identify the type and number of sub-modules required. The sub-module types are described below.

<(Note: For multiple init or per functions, insert new headers at the “Header 3” level – subset of “Sub-Module Functions section above” and follow the same sub-section design shown below . If none required, place the text “None”))>

Init: PwrSplyInit1

Design Rationale

None

(Processing of function)………

Refer to FDD.

Per: PwrSplyPer1

Design Rationale

None

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.

Server Runnable

None

Interrupt Functions

None

Module Internal (Local) Functions

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

Overfollow or rollover is intentional w.r.t Rte_Pim_SpiTrsmErrCntr.

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES008A PwrSply	See Synergy subproject version
6	CM600A_CSIG0CfgAndUse_Design	See the latest version in Synergy

28.3 - PwrSply_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace
Integration Manual

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES008A_PwrSply_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. 1.4.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. Krishna Anne

Work CR ID:

EA4#10122

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

N/A

Davinci 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:

Krishna Anne

Review Date :

03/20/17

Lead Peer Reviewer:

Shruthi Raghavan

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash James

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

PwrSply.c

Source File Revision:

4

Header File Name:

N/A

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

MDD Name:

PwrSply_MDD.doc

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

ES008A_PwrSply_Design

Revision:

1.7.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

Only for changes

for constant names

Yes

Comments:

Only for changes

for function names

Yes

Comments:

Only for changes

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

Only for changes

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

Only for changes

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Only for changes

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:

Only for changes

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

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Only for changes

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

Only for changes

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]

Only for changes

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Only for changes

Code formatting (indentation, placement of

Yes

Comments:

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

Only for changes

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Only for changes

Memory mapping for non-RTE code

Yes

Comments:

is per standard

Only for changes

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

Only for changes

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

Only for changes

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

Only for changes

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any FDD corrections needed

General Notes / Comments:

Reviewed only for the changes

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:

Krishna Anne

Review Date :

03/20/17

Lead Peer Reviewer:

Shruthi Raghavan

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash James

Sheet 4: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

PwrSply_MDD.doc

MDD Revision:

3

Source File Name:

PwrSply.c

Source File Revision:

4

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

Yes

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

Yes

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

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:

Krishna Anne

Review Date :

03/20/17

Lead Peer Reviewer:

Shruthi Raghavan

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash James

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

PwrSply.c

Source File Revision:

4

Source File Name:

Source File Revision:

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

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 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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Krishna Anne

Review Date :

03/20/17

Lead Peer Reviewer:

Shruthi Raghavan

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash James

Sheet 6: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Krishna Anne

Review Date :

03/20/17

Lead Peer Reviewer:

Shruthi Raghavan

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash James

29 - Component Implementation

Component Implementation

Component Documentation

29.1 - PwrUpSeq_IntegrationManual

Integration Manual

For

PwrUpSeq

VERSION: 3.0

DATE: 04-Jan-2017

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.	Description	Author	Version	Date
1	Initial version	Rijvi Ahmed	1.0	11-Apr-2015
2	Updated for FDD ver 1.2.0	Sankardu Varadapureddi	2.0	14-Jan-2016
3	Updated for FDD ver 1.5.0	Avinash James	3.0	04-Jan-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional 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	FDD – ES004A PwrUpSeq	See synergy sub project version
2	Software Naming Conventions	Process 03.05.00
3	Software Coding Standards	Process 03.05.00

Dependencies

SWCs

Module	Required Feature
IoHwAb	SetGpio – Set Pin P0_13

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

< Global function (except the ones that are defined in RTE modules) that is defined in this component but used by other function>

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file

Required Global Data Outputs

Refer DataDict.m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
PwrUpSeqInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
PwrUpSeqPer1	None	RTE 2ms Task
PwrTurnOffCtrl_Oper	None	On invocation of PwrTurnOffCtrl.Oper

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

Non RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

29.2 - PwrUpSeq_MDD

Module Design Document

For

Power Up Sequence

VERSION: 4.0

DATE: 04-JAN-2017

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.	Description	Author	Version	Date
1	Initial Version	Rijvi Ahmed	1.0	11-Apr-2015
2	Updated for FDD ver 1.2.0	Sankardu Varadapureddi	2.0	13-Jan-2016
3	Updated for FDD ver 1.4.0	Rijvi Ahmed	3.0	15-July-2016
4	Updated for FDD ver 1.5.0	Avinash James	4.0	04-Jan-2017

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 MDD pwrupseq & High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation of pwrupseq 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.2 Initialization Functions 11

7.2.1 PwrUpSeqInit1 11

7.2.1.1 Design Rationale 11

7.2.1.2 Module Outputs 11

7.3 PERIODIC FUNCTIONS 11

7.3.1 Per: PwrUpSeqPer1 11

7.3.1.1 Design Rationale 11

7.3.1.2 Store Module Inputs to Local copies 11

7.3.1.3 (Processing of function)……… 11

7.3.1.4 Store Local copy of outputs into Module Outputs 11

7.4 Server Runables 11

7.4.1 PwrTurnOffCtrl_Oper 11

7.4.1.1 Design Rationale 11

7.4.1.2 (Processing of function)……… 11

7.5 Interrupt Functions 12

7.6 Serial Communication Functions 13

7.7 Local Function/Macro Definitions 13

7.7.1 Local Function #1 13

7.7.1.1 Description 13

7.8 GLObAL Function/Macro Definitions 13

7.8.1 GLObAL Function #1 13

7.8.1.1 Description 13

7.9 TRANSIENT FUNCTIONS 13

8 Known Limitations With Design 14

9 UNIT TEST CONSIDERATION 15

1 Appendix 16

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

Sr. No.	Title	Version
1	MDD Guidelines	Process 04.02.01
2	Software Naming Conventions	Process 04.02.01
3	Software Coding Standards	Process 04.02.01
4	FDD – ES004A PwrUpSeq	See synergy sub project version

MDD pwrupseq & High-Level Description

None

Design details of software module

Graphical representation of pwrupseq

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)

N/A

Variable definition for enumerated types

Enum Name	Element Name	Value

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value
PINSTHI_CNT_U08	1	CNT	1U
Refer .m file

Global

Constant Name

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
N/A

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

PwrUpSeqInit1

Design Rationale

Refer FDD

Module Outputs

None

PERIODIC FUNCTIONS

Per: PwrUpSeqPer1

Design Rationale

None

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

Server Runables

PwrTurnOffCtrl_Oper

Design Rationale

None

(Processing of function)………

Refer to FDD

Interrupt Functions

None

Serial Communication Functions

None

Local Function/Macro Definitions

Local Function #1

Function Name	None	Type	Min	Max
Arguments Passed	None	<Refer MDD guidelines[1]>	<Refer MDD guidelines[1]>	<Refer MDD guidelines[1]>

Return Value	None

Description

N/A

GLObAL Function/Macro Definitions

GLObAL Function #1

Function Name	None	Type	Min	Max
Arguments Passed	None	<Refer MDD guidelines[1]>	<Refer MDD guidelines[1]>	<Refer MDD guidelines[1]>

Return Value	None

Description

N/A

TRANSIENT FUNCTIONS

None

Known Limitations With Design

UNIT TEST CONSIDERATION

Roll over of the PIM Rte_Pim_PwrTurnOffCtrlPrev() is intentional

Appendix

None

29.3 - PwrUpSeq_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES004A_PwrUpSeq_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. ES004A_PwrUpSeq_Impl_1.4.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. Shawn Penning

Work CR ID:

EA4#12439

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci 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:

Shawn Penning

Review Date :

06/21/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Brionna Spencer

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Shawn Penning

Review Date :

06/21/17

Component Type :

Application

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Brionna Spencer

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

PwrUpSeq.c

Source File Revision:

5

Header File Name:

N/A

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

MDD Name:

PwrUpSeq_MDD.doc

Revision:

4

FDD/SCIR/DSR/FDR/CM Name:

ES004A_PwrUpSeq_Design

Revision:

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

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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)

N/A

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

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

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

N/A

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

N/A

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

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

N/A

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:

Shawn Penning

Review Date :

06/21/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Brionna Spencer

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

PwrUpSeq.c

Source File Revision:

5

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

1.2

Poly Space version:

Windows User: eg. 2013b 2013B

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0

QAC version:

Windows User: eg 8.1.1-R

QAC sub project version:

Windows User: eg. TL_100A_1.1.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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

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

N/A

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

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:

Shawn Penning

Review Date :

06/21/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Brionna Spencer

30 - Component Implementation

Component Implementation

Component Documentation

30.1 - ES108A_ShtdwnMech Peer Review Checklists

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES108A_ShtdwnMech_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. 1.0.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. Mateusz Bartocha

Work CR ID:

EA4#10038

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci 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:

Mateusz Bartocha

Review Date :

03/23/17

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Hari Magidi

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

Port Interfaces does not match new StdDef implementation

Fixed - 23-Mar-2017

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

N/A

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Mateusz Bartocha

Review Date :

03/23/17

Component Type :

Application

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Hari Magidi

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

ShtdwnMech.c

Source File Revision:

1

Header File Name:

N.A.

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

MDD Name:

ShtdwnMech_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

ES108A_ShtdwnMech_Design

Revision:

1.0.1

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

No outputs

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

N/A

Comments:

requirements tracability in the FDD

Not applicable for EA4

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

N/A

Comments:

Files does not exist

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsiged conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

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:

Mateusz Bartocha

Review Date :

03/23/17

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Hari Magidi

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

ShtdwnMech_MDD.docx

MDD Revision:

1

Source File Name:

ShtdwnMech.c

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

N/A

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Mateusz Bartocha

Review Date :

03/23/17

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Hari Magidi

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

ShtdwnMech.c

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

1.1.0

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 4

QAC version:

Windows User: eg 8.1.1-R N.A.

QAC sub project version:

Windows User: eg 8.1.1-R N.A.

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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Mateusz Bartocha

Review Date :

03/23/17

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Hari Magidi

Sheet 7: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Mateusz Bartocha

Review Date :

03/23/17

Lead Peer Reviewer:

Kathleen Creager

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Hari Magidi

30.2 - ShtdwnMech_IntegrationManual

Integration Manual

For

ShtdwnMech

VERSION: 1.0

DATE: 21-Mar-2017

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

: ARM Cortex R4 Memory Usage
Sl. No.	Description	Author	Version	Date
1	Initial version	M. Bartocha	1.0	21-Mar-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional 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	FDD – ES108A ShtdwnMech	See Synergy subproject version
2	Software Naming Conventions	Process 04.02.01
3	Software Coding Standards	Process 04.02.01

Dependencies

SWCs

Module	Required Feature
ES999A_ElecGlbPrm	StrtUpState Threshold defines

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file

Required Global Data Outputs

Refer DataDict.m file

Specific Include Path present

NO

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
ShtdwnMechInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
ShtdwnMechPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
ShtdwnMech_START_SEC_CODE

* 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>

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

<This section is for appendix>

30.3 - ShtdwnMech_MDD

Module Design Document

For

ShtdwnMech

March 21, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Mateusz Bartocha,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	M. Bartocha	1.0	21-Mar-2017

Table of Contents

1 Introduction 4

2 ES108A_ShtdwnMech & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of <Component Name> 6

3.2 Data Flow Diagram 6

3.2.1 Component level DFD 6

3.2.2 Function level DFD 6

4 Constant Data Dictionary 7

4.1 Program (fixed) Constants 7

4.1.1 Embedded Constants 7

5 Software Component Implementation 8

5.1 Sub-Module Functions 8

5.1.1 Init: ShtdwnMech_Init1 8

5.1.1.1 Design Rationale 8

5.1.1.2 Module Outputs 8

5.1.2 Per: ShtdwnMech _Per1 8

5.1.2.1 Design Rationale 8

5.1.2.2 Store Module Inputs to Local copies 8

5.1.2.3 (Processing of function)……… 8

5.1.2.4 Store Local copy of outputs into Module Outputs 8

5.2 Server Runables 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 8

5.5 GLOBAL Function/Macro Definitions 8

6 Known Limitations with Design 9

7 UNIT TEST CONSIDERATION 10

Appendix A Abbreviations and Acronyms 11

Appendix B Glossary 12

Appendix C References 13

Introduction

None

ES108A_ShtdwnMech & High-Level Description

None

Design details of software module

Graphical representation of <Component Name>

Data Flow Diagram

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Refer to the DataDictionary of the design

Software Component Implementation

Refer to FDD.

Sub-Module Functions

Init: ShtdwnMech_Init1

Design Rationale

None

Module Outputs

Refer to FDD.

Per: ShtdwnMech _Per1

Design Rationale

None

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.

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	EA4 Software Naming Conventions.doc	1.0.0
4	Software Design and Coding Standards.doc	2.1

31 - Component Implementation

Component Implementation

Component Documentation

31.1 - SinVltgGenn_IntegrationManual

Integration Manual

For

Sine Voltage Generation

VERSION: 1

DATE: 11-June-2015

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

Revision History

Version	Description	Author	Date
1	Initial version	Sankardu Varadapureddi	2-May-2015

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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

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	Software Naming Conventions	Process 4.00.00
2	Software Coding Standards	Process 4.00.00
3	FDD – ES300A_SinVltgGenn_Design	See Synergy sub project version

Dependencies

SWCs

Module	Required Feature
None

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

SinVltgGennPer1

SinVltgGennPer2

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

See design model for details.

Required Global Data Outputs

See design model for details.

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
SinVltgGennInit1	None	RTE (init)

Runnable	Scheduling Requirements	Trigger
SinVltgGennPer1		MotCtrlISR
SinVltgGennPer2		MotCtrlISR

Memory Map REQUIREMENTS

Mapping

Memory Section *	Contents	Notes
MotCtrl_START_SEC_CODE	Code section for Motor Control scheduled functions	Constants are defined at function level. Memory mapping need to be adjusted accordingly.

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

Usage

Feature	RAM	ROM
None

Non RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in configurator

RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

31.2 - SinVltgGenn_MDD

Module Design Document

For

Sine Voltage Generation

Aug 09, 2017

Prepared By:

Matthew Leser,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Version	Description	Author	Date
1	Initial version	Sankardu Varadapureddi	2-May-2015
2	Updated to fix A1587	Selva Sengottaiyan	17-Sep-2015
3	Updated for v1.30 and 1.4.0 of the FDD	Selva Sengottaiyan	20-Mar-2016
4	Updated graph and added new function	Matthew Leser	09-Aug-2017

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 SinVltgGenn & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of SinVltgGenn 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.2 Initialization Functions 9

5.2.1 Init: SinVltgGennInit1 9

5.2.1.1 Design Rationale 9

5.2.1.2 Module Internal 9

5.3 PERIODIC FUNCTIONS 9

5.3.1 Per: SinVltgGennPer1 9

5.3.1.1 Design Rationale 9

5.3.1.2 Processing of Function 9

5.3.2 Per: SinVltgGennPer2 9

5.3.2.1 Design Rationale 9

5.3.2.2 Processing of Function 9

5.4 Server Runables 9

5.5 Interrupt Functions 10

5.6 Module Internal (Local) Functions 10

5.6.1 Local Function #1 10

5.6.1.1 Description 10

5.7 GLOBAL Function/Macro Definitions 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

None

Scope

None

SinVltgGenn & High-Level Description

The component contains two source files, both described in this MDD: CDD_ SinVltgGenn.c contains the RTE init runnable; CDD_SinVltgGenn_MotCtrl.c contains the motor control runnable.

Refer the Design for high level Description

Design details of software module

Graphical representation of SinVltgGenn

Data Flow Diagram

None

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
None

Software Component Implementation

Note: All the non RTE signals defined in m file are implemented as global variables managed by motor control manager. RTE cannot manage motor control runnable inputs and outputs.

Sub-Module Functions

None

Initialization Functions

Init: SinVltgGennInit1

Design Rationale

None

Module Internal

See design model for details.

PERIODIC FUNCTIONS

Per: SinVltgGennPer1

Design Rationale

Inputs and outputs are globals since its non RTE (MotorControl ISR) function.

Note: Instead of division operation, multiplication with ‘NXTRFIXDPT_P16TOFLOAT_ULS_F32’ used.

Processing of Function

See design model for details.

Per: SinVltgGennPer2

Design Rationale

Inputs and outputs are globals since its non RTE (MotorControl ISR) function.

Note: outputs are not limited in SW as max limit is set to U32 range in design.

Processing of Function

See design model for details.

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	MotCtrlPhaOnTiCal	Type	Min	Max
Arguments Passed	MotAgElec_MotRevElec_T_u0p16	uint16 (used as a fixed point representation)	0	0.999
	MotPhaAdv_MotRevElec_T_u0p16	uint16 (used as a fixed point representation)	0	0.999
	PhaDptOffsX_MotRevElec_T_f32	float32	-0.999	0.999
	MotModlnIdx_Uls_T_f32	float32	0	1


Return Value	MotCtrlPhaOnTiX_NanoSec_T_u32	uint32	0	71429

Description

Function corresponds to 'Subsystem1/Subsystem2/Subsystem3' block implementation. Subsystems 1 through 3 have common processing.

Local Function #2

Function Name	MotCtrlPhaOnTiCalc	Type	Min	Max
Arguments Passed	CmuOffs_NanoSec_T_u32	uint32	0	71429
	PwmPerd_NanoSec_T_u32	uint32	55555	71429
	ModIndxPha_Uls_T_f32	float32	0.0	71429.0
	FetFailDC_UlsT_f32	float32	0.0	71429.0
	FetFailBias_Uls_T_f32	float32	0.0	1.0
Return Value	MotCtrlPhaOnTiX_NanoSec_T_u32	uint32	0	71429

Description

‘Calculate MotCtrlPhaOnTiA/B/C’ block implementation.

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES300A_SinVltgGenn_Design	See Synergy sub project version

31.3 - SinVltgGenn_Review

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code .c
Source Code MotCtrl.c
MDD
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES300A_SinVltgGenn_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. ES300A_SinVltgGenn_Impl_2.0.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. Matthew Leser

Work CR ID:

EA4#12922

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci 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:

Matthew Leser

Review Date :

09/11/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

N/A

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

09/11/17

Component Type :

CDD

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code .c

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_SinVltgGenn.c

Source File Revision:

5

Header File Name:

CDD_SinVltgGenn.h

Header File Revision:

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

Header File Name:

CDD_SinVltgGenn_MotCtrl_MemMap.h

Header File Revision:

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

Header File Name:

CDD_SinVltgGenn_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. 1

MDD Name:

SinVltgGenn_MDD.doc

Revision:

4

FDD/SCIR/DSR/FDR/CM Name:

ES300A_SinVltgGenn_Design

Revision:

2.0.0/2.1.0/2.2.0/2.3.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

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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)

N/A

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

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

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

N/A

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

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

N/A

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:

Matthew Leser

Review Date :

09/11/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: Source Code MotCtrl.c

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_SinVltgGenn_MotCtrl.c

Source File Revision:

6

Header File Name:

CDD_SinVltgGenn.h

Header File Revision:

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

Header File Name:

CDD_SinVltgGenn_MotCtrl_MemMap.h

Header File Revision:

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

Header File Name:

CDD_SinVltgGenn_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. 1

MDD Name:

SinVltgGenn_MDD.doc

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

ES300A_SinVltgGenn_Design

Revision:

2.0.0/2.1.0/2.2.0/2.3.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

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.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

N/A

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.

Yes

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

Yes

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:

Matthew Leser

Review Date :

09/11/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

SinVltgGenn_MDD.doc

MDD Revision:

4

Source File Name:

CDD_SinVltgGenn.c

Source File Revision:

5

Source File Name:

CDD_SinVltgGenn_MotCtrl.c

Source File Revision:

6

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

09/11/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (PolySpace Review)

Source File Name:

CDD_SinVltgGenn.c

Source File Revision:

5

Source File Name:

CDD_SinVltgGenn_MotCtrl.c

Source File Revision:

6

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013B

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0

QAC version:

Windows User: eg 8.1.1-R

QAC sub project version:

Windows User: eg. TL_100A_1.1.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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Matthew Leser

Review Date :

09/11/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

32 - Component Implementation

Component Implementation

Component Documentation

32.1 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
ES100A	88	SysStMod.c	SysStModPer1	222-230,313	I
ES100A	89	SysStMod.c	SysStModPer1	202-210,309	I
ES100A	65	SysStMod.c	SysStModPer1	248	I
ES100A	66	SysStMod.c	SysStModPer1	251	I
ES100A	67	SysStMod.c	SysStModPer1	250	I
ES100A	68	SysStMod.c	SysStModPer1	252	I
ES100A	69	SysStMod.c	SysStModPer1	249	I
ES100A	87	SysStMod.c	SysStModInit1	142-144	I
ES100A	85	SysStMod.c	SysStModPer1	212-220,305	I
ES100A	48	SysStMod.c	SysStModPer1	246	I
ES100A	187	SysStMod.c	SysStModPer1	313	I
ES100A	188	SysStMod.c	SysStModPer1	313	I
ES100A	78	SysStMod.c	SysStModPer1	191,294-331	P	Integration dependent - runnable placement should be noted in integration manual
ES100A	77	SysStMod.c	SysStModPer1	190,294-331	P	Integration dependent - periodic is scheduled at 2ms in Developer model
ES100A	98	SysStMod.c	SysStModPer1	295,297	I
ES100A	73	SysStMod.c	SysStModPer1	257-290	I
ES100A	70	SysStMod.c	SysStModPer1	247	I
ES100A	91	SysStMod.c	SysStModPer1	295,297	I
ES100A	90	SysStMod.c	SysStModPer1	301	I
ES100A	93	SysStMod.c	SysStModPer1	295,297	I
ES100A	92	SysStMod.c	SysStModPer1	295,297	I
ES100A	95	SysStMod.c	SysStModPer1	315-321	I
ES100A	94	SysStMod.c	SysStModPer1	301	I
ES100A	97	SysStMod.c	SysStModPer1	295,297	I
ES100A	96	SysStMod.c	SysStModPer1	295,297	I
ES100A	99	SysStMod.c	SysStModPer1	325	I
ES100A	76	SysStMod.c	SysStModPer1	257-290	I
ES100A	32	SysStMod.c	SysStModPer1	333	I
ES100A	51	SysStMod.c	SysStModPer1	333	I
ES100A	53	SysStMod.c	SysStModPer1	329	I

32.2 - SysStMod_IntegrationManual

Integration Manual

For

System States and Modes

VERSION: 1

DATE: 20-Mar-2015

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

Revision History

Version	Description	Author	Date
1	Initial version	Owen Tosh	20-Mar-2015

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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

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	Software Naming Conventions	Process 03.05.00
2	Software Coding Standards	Process 03.05.00

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

See design model for details.

Required Global Data Outputs

See design model for details.

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
SysStModInit1	None	RTE (init)

Runnable	Scheduling Requirements	Trigger
SysStModPer1	After all modules that provide inputs to this module	RTE (2 ms)

Memory Map REQUIREMENTS

Mapping

Memory Section *	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Non RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in configurator

RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

32.3 - SysStMod_MDD

Module Design Document

For

System States and Modes

VERSION: 2

DATE: 05-Apr-2016

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

Revision History

Version	Description	Author	Date
1	Initial version	Owen Tosh	25-Mar-2015
2	Updated for FDD ver 1.3.0	Sankardu Varadapureddi	05-Apr-2016

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 SysStMod & High-Level Description 6

4 Design details of software module 7

4.1 Graphical representation of SysStMod 7

5 Variable Data Dictionary 8

5.1 User defined typedef definition/declaration 8

5.2 Variable definition for enumerated types 8

6 Constant Data Dictionary 9

6.1 Program(fixed) Constants 9

6.1.1 Embedded Constants 9

6.1.1.1 Local 9

6.1.1.2 Global 9

6.1.2 Module specific Lookup Tables Constants 10

7 Software Module Implementation 11

7.1 Sub-Module Functions 11

7.2 Initialization Functions 11

7.2.1 Init: SysStMd_Init1 11

7.2.1.1 Design Rationale 11

7.2.1.2 Module Internal 11

7.3 PERIODIC FUNCTIONS 11

7.3.1 Per: SysStMd_Per1 11

7.3.1.1 Design Rationale 11

7.3.1.2 Processing of Function 11

7.4 Interrupt Functions 11

7.5 Serial Communication Functions 11

7.6 Local Function/Macro Definitions 11

7.7 GLObAL Function/Macro Definitions 11

8 Known Limitations With Design 12

9 UNIT TEST CONSIDERATION 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	Process 03.05.00
2	Software Naming Conventions	Process 03.05.00
3	Software Coding Standards	Process 03.05.00

SysStMod & High-Level Description

This module manages the overall system state based on ignition, startup test completion, and fault status. It arbitrates between the various demands on the system state and manages the transition decisions with a lookup table, dependent on the current state.

Design details of software module

Graphical representation of SysStMod

Variable Data Dictionary

User defined typedef definition/declaration

Typedef Name

Element Name

User Defined Type

Legal Range

(min)

Legal Range

(max)

None

Variable definition for enumerated types

Enum Name	Element Name	Value
None

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value
SYSSTREQENBIT_CNT_U16	1	Count	0x04
PWRSPLYENREQBIT_CNT_U16	1	Count	0x10
SYSSTFLTOUTPREQDIBIT_CNT_U16	1	Count	0x08
SYSSTREQDIBIT_CNT_U16	1	Count	0x02
SYSSTWRMININCMPLBIT_CNT_U16	1	Count	0x01

Global

Constant Name

None

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
See design M file for details

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

Init: SysStModInit1

Design Rationale

None

Module Internal

See design model for details.

PERIODIC FUNCTIONS

Per: SysStMdPer1

Design Rationale

The logic around building the transition vector does not match the design model exactly for efficiency and coding standard reasons. They are identical functionally, however.

Processing of Function

See design model for details.

Interrupt Functions

None

Serial Communication Functions

None

Local Function/Macro Definitions

None

GLObAL Function/Macro Definitions

None

Known Limitations With Design

None

UNIT TEST CONSIDERATION

None

32.4 - SysStMod_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES100A_SysStMod_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. 1.1.0

Change Owner:

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

Work CR ID:

EA4#5086

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci Files

Comments:

In .m file "SysStReqEn" is renamed as "SysStReqEna" and "PwrSplyEnReq" is renamed as "PwrSplyEnaReq". So

only corresponding changes are reviewed.

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:

Sankardu Varadapureddi

Review Date :

04/05/16

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Sankardu Varadapureddi

Review Date :

04/05/16

Component Type :

Application

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

SysStMod.c

Source File Revision:

4

Header File Name:

N/A

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

MDD Name:

SysStMod_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES100A_SysStMod_Design

Revision:

1.3.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

Yes

for variable names

Yes

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

Yes

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

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:

Sankardu Varadapureddi

Review Date :

04/05/16

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

SysStMod_MDD.docx

MDD Revision:

2

Source File Name:

SysStMod.c

Source File Revision:

4

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Sankardu Varadapureddi

Review Date :

04/05/16

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

SysStMod.c

Source File Revision:

4

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

1

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

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 1.1.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 Analysis

N/A

Comments:

Compliance Guideline

Ref comments

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Ref comments

Do all MISRA deviation comments use approved

N/A

Comments:

deviation tags

Ref comments

Cyclomatic complexity and Static path count OK

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

N/A

Comments:

for all functions in the component per Design

Ref comments

and Coding Standards rule [N47]

General Notes / Comments:

Only names of input ports are renamed. So QAC and Polysapce are reran and new result reports are stored.

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:

Sankardu Varadapureddi

Review Date :

04/05/16

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

33 - Component Implementation

Component Implementation

Component Documentation

33.1 - TmplMonr_IntegrationManual

Integration Manual

For

TmplMonr

VERSION: 2.0

DATE: 27-Mar-2017

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Krishna Anne	1.0	24-Mar-2017
2	Modified runnable scheduling statements	Krishna Anne	2.0	27-Mar-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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional 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	FDD – ES005C TmplMonr	See Synergy subproject version
2	Software Naming Conventions	Process 04.02.00
3	Software Coding Standards	Process 04.02.00

Dependencies

SWCs

Module	Required Feature
Spi_Renesas_Ar4.0.3_01.06.05_0
CM600A_CSIG0CfgAndUse_Design	Channel and Sequence definitions and API requirements.
CDD_EcmOutpAndDiagc	Needed for enumeration type definition. CDD_EcmOutpAndDiagc.h is required to be included in Rte_UserTypes.h file in integration project.

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
See CM600A_CSIG0CfgAndUse_Design requirements.

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file

Required Global Data Outputs

Refer DataDict.m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
TmplMonrInit1	None	RTE (init)

Runnable	Scheduling Requirements	Trigger
TmplMonrPer1	At the start of Higher priority 2ms task group (Higher priority 2ms tasks run in all system states)	RTE 2ms
TmplMonrPer2	At the end of Lower priority 2ms task group. This runnable should be scheduled before states and modes computes a new system state. (The task group that Per2 is running is assumed to be blocked from execution during the shutdown process).	RTE 2ms
TmplMonrPer3	After TmplMonrPer1 in Higher priority 2ms task group (Higher priority 2ms tasks run in all system states)	RTE 2ms

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
TmplMonr_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None.

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

33.2 - TmplMonr_MDD

Module Design Document

For

Temporal Monitor Function

Mar 24, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	Krishna Anne	1.0	24-Mar-2017
Removed limitations from previous version	Krishna Anne	2.0	27-Mar-2017

Table of Contents

1 Introduction 6

1.1 Purpose 6

2 TmplMonr & High-Level Description 7

3 Design details of software module 8

3.1 Graphical representation of TmplMonr 8

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

3.2.2 Function level DFD 8

4 Constant Data Dictionary 9

4.1 Program (fixed) Constants 9

4.1.1 Embedded Constants 9

5 Software Component Implementation 10

5.1 Sub-Module Functions 10

5.1.1 Init: TmplMonrInit1 10

5.1.1.1 Design Rationale 10

5.1.1.2 Module Outputs 10

5.1.2 Per: TmplMonrPer1 10

5.1.2.1 Design Rationale 10

5.1.2.2 Store Module Inputs to Local copies 10

5.1.2.3 (Processing of function)……… 10

5.1.2.4 Store Local copy of outputs into Module Outputs 10

5.1.3 Per: TmplMonrPer2 10

5.1.3.1 Design Rationale 10

5.1.3.2 Store Module Inputs to Local copies 10

5.1.3.3 (Processing of function)……… 10

5.1.3.4 Store Local copy of outputs into Module Outputs 11

5.1.4 Per: TmplMonrPer3 11

5.1.4.1 Design Rationale 11

5.1.4.2 Store Module Inputs to Local copies 11

5.1.4.3 (Processing of function)……… 11

5.1.4.4 Store Local copy of outputs into Module Outputs 11

5.2 Server Runables 11

5.3 Interrupt Functions 11

5.4 Module Internal (Local) Functions 11

5.4.1 Local Function #1 11

5.4.1.1 Design Rationale 11

5.4.1.2 Processing 11

5.4.2 Local Function #2 12

5.4.2.1 Design Rationale 12

5.4.2.2 Processing 12

5.4.3 Local Function #3 12

5.4.3.1 Design Rationale 12

5.4.3.2 Processing 12

5.4.4 Local Function #4 12

5.4.4.1 Design Rationale 12

5.4.4.2 Processing 12

5.4.5 Local Function #5 12

5.4.5.1 Design Rationale 13

5.4.5.2 Processing 13

5.4.6 Local Function #6 13

5.4.6.1 Design Rationale 13

5.4.6.2 Processing 13

5.4.7 Local Function #7 13

5.4.7.1 Design Rationale 13

5.4.7.2 Processing 13

5.4.8 Local Function #8 13

5.4.8.1 Design Rationale 14

5.4.8.2 Processing 14

5.4.9 Local Function #9 14

5.4.9.1 Design Rationale 14

5.4.9.2 Processing 14

5.4.10 Local Function #10 14

5.4.10.1 Design Rationale 14

5.4.10.2 Processing 14

5.5 GLOBAL Function/Macro Definitions 15

6 Known Limitations with Design 16

7 UNIT TEST CONSIDERATION 17

Appendix A Abbreviations and Acronyms 18

Appendix B Glossary 19

Appendix C References 20

Introduction

Purpose

Module design document for Temporal Monitor Function.

TmplMonr & High-Level Description

Refer to FDD

Design details of software module

Graphical representation of TmplMonr

Data Flow Diagram

Component level DFD

N/A

Function level DFD

N/A

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Refer to the Data Dictionary of the design

Software Component Implementation

Sub-Module Functions

The sub-module functions are grouped based on similar functionality that needs to be executed in a given “State” of the system (refer States and Modes). For a given module, the MDD will identify the type and number of sub-modules required. The sub-module types are described below.

Init: TmplMonrInit1

Design Rationale

None

Module Outputs

Refer to FDD

Per: TmplMonrPer1

Design Rationale

None

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: TmplMonrPer2

Design Rationale

None

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: TmplMonrPer3

Design Rationale

None

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

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	TMFInitTest	Type	Min	Max
Arguments Passed	None
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “TMF Init Test” block of the Simulink model of the design.

Local Function #2

Function Name	TMFInitTestCase0	Type	Min	Max
Arguments Passed	None
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “TMF Init Test” block case 0 of the Simulink model of the design.

Local Function #3

Function Name	TMFInitTestCase10To11Case15To17	Type	Min	Max
Arguments Passed	None
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “TMF Init Test” block case 10, case 11, case 15, case 16 and case 17 of the Simulink model of the design.

Local Function #4

Function Name	TMFInitTestCase13	Type	Min	Max
Arguments Passed	None
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “TMF Init Test” block case 13 of the Simulink model of the design.

Local Function #5

Function Name	TMFInitTestCase18	Type	Min	Max
Arguments Passed	None
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “TMF Init Test” block case 18 of the Simulink model of the design.

Local Function #6

Function Name	TMFInitTestCase19	Type	Min	Max
Arguments Passed	None
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “TMF Init Test” block case 19 of the Simulink model of the design.

Local Function #7

Function Name	TMFInitTestCase20	Type	Min	Max
Arguments Passed	None
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “TMF Init Test” block case 20 of the Simulink model of the design.

Local Function #8

Function Name	TMFInitTestCase21	Type	Min	Max
Arguments Passed	None
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “TMF Init Test” block case 21 of the Simulink model of the design.

Local Function #9

Function Name	TMFInitTestCase53	Type	Min	Max
Arguments Passed	None
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “TMF Init Test” block case 53 of the Simulink model of the design.

Local Function #10

Function Name	SpiAsyncTx	Type	Min	Max
Arguments Passed	Channel_Cnt_T_u16	Spi_ChannelType	0U	65535U
	TxData_Cnt_T_u16	Spi_DataType	0U	65535U
	Sequence_Cnt_T_u08	Spi_SequenceType	0U	255U
Return Value	N/A

Design Rationale

None

Processing

(Place flowchart/design for local function)

This function is defined in order to call Spi_WriteIB and Call_Spi_AsyncTransmit together in a sequence.

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None.

UNIT TEST CONSIDERATION

Rte_Pim_TrsmErrCntr is a free running counter hence Overflow or rollover is intentional.

Abbreviations and Acronyms

Abbreviation or Acronym	Description
DFD	Design functional diagram
MDD	Module design Document

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	Software Naming Conventions.doc	2.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – ES005C TmplMonr	See Synergy subproject version

33.3 - TmplMonr_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES005C_TmplMonr_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. ES005C_TmplMonr_Impl_1.2.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. Shawn Penning

Work CR ID:

EA4#13813

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci 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:

Shawn Penning

Review Date :

08/09/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

N/A

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

N/A

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Shawn Penning

Review Date :

08/09/17

Component Type :

Application

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

TmplMonr.c

Source File Revision:

3

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:

TmplMonr_MDD.doc

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

ES005A_TmplMonr_Design

Revision:

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

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

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)

N/A

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

N/A

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

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

N/A

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

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

N/A

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:

Inline used in SPI function.

coding standard rules

Update 8/15/17: Removed Inline

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:

Shawn Penning

Review Date :

08/15/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (PolySpace Review)

Source File Name:

TmplMonr.c

Source File Revision:

3

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013B

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0

QAC version:

Windows User: eg 8.1.1-R

QAC sub project version:

Windows User: eg. TL_100A_1.1.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 Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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:

Shawn Penning

Review Date :

08/09/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

34 - Component Implementation

Component Implementation

Component Documentation

34.1 - ES400A_TunSelnMngt_Integration_Manual

Integration Manual

For

ES400A TunSelnMngt

VERSION: 4.0

DATE: 29-Aug-2016

Prepared By:

Kevin Smith

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	Approved By
1	Initial version	K. Smith	1.0	09-Oct-15	-
2	Updated for version 1 of the design	K. Smith	2.0	04-Apr-16
3	Removed CalUsgProtn exclusive area	N. Saxton	3.0	06-May-16
4	Anomaly correction for EA4#6672	K. Smith	4.0	29-Aug-16

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 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	Process 04.02.00
2	Software Naming Conventions	Process 04.02.00
3	Coding standards	Process 04.02.00
4	ES400A_TunSelnMngt_Design	See Synergy subproject version

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

TunSelnMngt_Cfg_private.h – Genereated by Configurator
TunSelnMngt_Cfg_private.c – Genereated by Configurator

Da Vinci Parameter Configuration Changes

All the parameters are generated by the data dictionary tool based on the configuration for the project

Parameter	Notes		SWC

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Exclusive Areas

Constant	Notes	SWC
TunSelnMngtIntDataProtnExclsvArea	Exclusive area needs to protect periodic access of PIMs from asynchronous updates by server runnables SetCalPageReq and CopyCalPage. Integrator verify if client calls to server runnables are interrupt or task based and set up exclusive area to properly protect access.

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Required Global Data Outputs

Specific Include Path present

Yes. TunSelnMngt.h must also be included in Rte_UserTypes.h for non-RTE generated type definitions.

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
TunSelnMngtInit1	This init function should be performed before any calibration access is done by another component and after DiagcMgr has initialized. However, if the calibration access is only to common calibrations, then there would be no impact.	RTE

Runnable	Scheduling Requirements	Trigger
TunSelnMngtPer1	None	RTE 10ms

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

*See DataDict.m

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

The following settings are recommend for online calibration support and DAQ access. This only applies to projects that XCP settings are generated by GENy.

Configurable Options	Setting	Rationale
Enable Calibration	True	Required to be true to enable write commands such as DOWNLOAD.
XCP Control	True	Required to enable or disable XCP access
Open Command Interface	True	Required for XCP service E8 and E9 support
Prescaler	True	Required to support scaling the DAQ timing (example, 2ms DAQ can be scaled in mulitples of 2ms to create DAQs running at 4ms, 8ms, 10ms, etc).
User Defined Commands	True	Required for additional functions built into XCP commands
Page Switching	True	Required for online calibration functions to properly operate.
General Page Info	True
Copy Page	True

34.2 - ES400A_TunSelnMngt_MDD

Module Design Document

For

TunSelnMngt

August 29, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Kevin Smith,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date	Approved By
Initial Version	K. Smith	1	07-Apr-16
Updated program flow diagrams	N. Saxton	2	06-May-16
Updates to flow charts for anomaly EA4#6672 corrections	K. Smith	3	29-Aug-16

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 TunSelnMngt & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of TunSelnMngt 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

4.2 Variable Data Dictionary 8

4.2.1 User Defined Typedef Definition/Declaration 8

4.2.1.1 Static Structures 8

4.2.1.2 Dynamic Structures and Enums 9

4.2.2 User Defined Enumerated Types 10

5 Software Component Implementation 11

5.1 Sub-Module Functions 11

5.1.1 Init: TunSelnMngtInit1 11

5.1.2 Per: TunSelnMngtPer1 13

5.2 Server Runnables 15

5.2.1 CopyCalPageReq 15

5.2.2 GetCalPageReq 16

5.2.3 GetSegInfoReq 17

5.2.4 OnlineTunRamAdrMpg 18

5.2.5 SetCalPageReq 19

5.3 Interrupt Functions 20

5.4 Module Internal (Local) Functions 20

5.4.1 SwtCalIdx 20

5.4.2 IdxChgMngt 21

5.4.3 MemCopy32Bit 23

5.4.4 MemCopy8Bit 24

5.4.5 SegModAdrInfo 25

5.4.6 SegModStdInfo 26

5.4.7 SegModAdrMpg 27

5.5 GLOBAL Function/Macro Definitions 28

6 Known Limitations with Design 29

7 UNIT TEST CONSIDERATION 30

Appendix A Abbreviations and Acronyms 31

Appendix B Glossary 32

Appendix C References 33

Introduction

Purpose

This MDD aids in documenting the implementation of ES400A Tuning Selection Management.

Scope

The following definitions are used throughout this document:

Shall: indicates a mandatory requirement without exception in compliance.
Should: indicates a mandatory requirement; exceptions allowed only with documented justification.
May: indicates an optional action.

TunSelnMngt & High-Level Description

Tuning Selection Management (TunSelnMngt) provides the ability to change run-time calibrations during operation. The component also provides a RAM buffer for online calibration changes over XCP for tuning processes.

Design details of software module

Graphical representation of TunSelnMngt

Data Flow Diagram

None

Component level DFD

None

Function level DFD

None

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Values between the brackets [] are the ranges that the configurable constants could be defined as for a given integration. These values are generated by Configurator before the software build.

Constant Name	Resolution	Units	Value
MAXINITIDXCNT_CNT_U08	Uint8	Cnt	[0-255]
MAXRTIDXCNT_CNT_U08	Uint8	Cnt	[0-255]
MAXONLINECALCFGCNT_CNT_U08	Uint8	Cnt	[0-255]
ONLINECALGROUPS_CNT_U08	Uint8	Cnt	[0-255]
ONLINECALRAMTBL_CNT_U16	Uint16	Cnt	[0-65535]
PRMPTRTBLSIZEINWORD_CNT_U16	Uint16	Cnt	[0-65535]

Variable Data Dictionary

The following type definitions are found in the private header of this component.

User Defined Typedef Definition/Declaration

Static Structures

The following table contains structures are static in their definition. However, internal elements may change based on the configuration of the project but the high level content is the same. These elements are described at the bottom of the table.

Typedef Name	Element Name	User Defined Type	Legal Range (min)	Legal Range (max)
TunSelnRamTblRec1	PrmRefTblPtr	Rte_ParameterRefTabType	N/A	N/A
	PrmTblCrc_u32	Uint32	0	4294967295
TunSelnIdxTblRec1	SrcIdx_u16	Uint16	0	65535
	DestIdx_u16	Uint16	0	65535
	SigIdx_u08	Uint8	0	255
TunSelnOnlineCalIdxTblRec1	RamStructPtr_u08	UInt8*	0	255
	StructSize_u16	Uint16	0	65535
	TblIdx_u16	Uint16	0	65535
	GroupIdx_u08	Uint8	0	255

Rte_ParameterRefTabType is a structure of void pointers that point to the various calibration component structures. This type is generated by the RTE based on the configuration of the integration.

Dynamic Structures and Enums

The following table contains structures are dynamic in their definition. The contents contained will vary from project to project. The intent of this table is to document their purpose.

Entry Type	Typedef Name	Example Element(s)	Variable Type	Value	Comment
Enum	OnlineCalGroup1	GroupA	N/A	0	This enum contains a number representation for each calibration group that is generated for online calibration from A=0 to Z=26. Groups are defined by a letter suffix.
		GroupB	N/A	1
Struct	<GroupName>Typ GroupATyp	<Cal Region><Cal Cmp Name><Online Group> CalRegn01CmnGroupA	RTE Generated	N/A	This structure is generated based on the online groups configured. Each group will generate a structure and contain all calibration software components within that group.
Union	OnlineCalTblRec1	Byte[<RAM Size>]	Unit8	N/A	This structure combines all the online calibration groups into data type for assignment to the RAM buffer. The ‘byte’ element is used to access the entire buffer on a byte-by-byte basis and ensure that the RAM is properly sized.
		<GroupName>	<GroupName>Typ	N/A

User Defined Enumerated Types

Enum Name	Element Name	Value
GetSegModeSegInfo1	GETSEGMODSEGINFO_ADR	0
	GETSEGMODSEGINFO_LEN	1
GetSegModeMpgIdx1	GETSEGMODMPGIDX_SRCADR	0
	GETSEGMODMPGIDX_DESTADR	1
	GETSEGMODMPGIDX_LEN	2

Software Component Implementation

Sub-Module Functions

Init: Init1

Design Rationale

The initialization function creates two copies of the RTE generated flash table in to RAM. A CRC is performed on each of the copies to ensure that they match. The function also adjusts the tables to load the appropriate initialization and run-time calibrations indexes that are required by the application.

Processing

Module Outputs

None

Per: Per1

Design Rationale

Processing

Module Outputs

None

Server Runnables

CopyCalPageReq

Design Rationale

This function is called by the XCP master and queues the copy of the calibrations contained in the selected group, or segment, into the RAM buffer. The actual copy is performed by TunSelnMngt’s main periodic function, but this runnable logs the current state of TunSelnMngt and marks the copy in progress.

(Processing of function)………

Module Outputs

None

GetCalPageReq

Design Rationale

This function is called by the XCP master and returns the page with the request XCP and ECU access for a given segment.

(Processing of function)………

Module Outputs

None

GetSegInfoReq

Design Rationale

This function is called by the XCP master and returns the requested information for the provided segment.

(Processing of function)………

Module Outputs

None

OnlineTunRamAdrMpg

Design Rationale

This function is called by the XCP master. During tuning, tools such as eTool and CANape will read calibration values from their flash addresses because that is how the A2L file is defined. However, when the calibrations are access from RAM, the user does not always know the exact address the calibration is located. This function calculates the RAM address for a given calibration to the XCP function for reading and writing.

(Processing of function)………

Module Outputs

None

SetCalPageReq

Design Rationale

This function is called by the XCP master. This function will set the status of the calibration page for a given segment.

(Processing of function)………

Module Outputs

None

Interrupt Functions

None

Module Internal (Local) Functions

SwtCalIdx

Function Name	SwtCalIdx	Type	Min	Max
Arguments Passed	N/A
Return Value	N/A

Design Rationale

This function manages the RAM buffer access and switches the calibration index between the two copies in RAM.

Processing

IdxChgMngt

Function Name	IdxChgMngt	Type	Min	Max
Arguments Passed	SeldIdx_Cnt_T_u08	Uint8	0	255
	GendCalTblSize_Cnt_T_u08	Uint8	0	255
	GendCalTbl_T_rec	TunSelnIdxTblRec1*	0	4294967295
Return Value	IdxFound_Cnt_T_logl	Boolean	FALSE	TRUE

Design Rationale

Processing

MemCopy32Bit

Function Name	MemCopy32Bit	Type	Min	Max
Arguments Passed	Des_Arg	Void	0	4294967295
	Src_Arg	Void	0	4294967295
	Len_Arg	Uint16	0	65535
Return Value	N/A

Design Rationale

The 32-bit mem copy function is used to move calibration pointers from flash to RAM. The void pointers are internally assigned to a uint32 pointer before the processing loop begins.

Processing

MemCopy8Bit

Function Name	MemCopy8Bit	Type	Min	Max
Arguments Passed	Des_Arg	Void	0	4294967295
	Src_Arg	Void	0	4294967295
	Len_Arg	Uint16	0	65535
Return Value	N/A

Design Rationale

The 8-bit mem copy function is used to move calibration segments into the RAM space. Since the length of the segments is not guaranteed to be a 32-bit even address, 8-bit was selected to ensure that only the bytes required to be moved are performed. The void pointers are internally assigned to a uint8 pointer before the processing loop begins.

Processing

SegModAdrInfo

Function Name	SegModAdrInfo	Type	Min	Max
Arguments Passed	Seg_Arg	UInt8	0	255
	SegInfo_Arg	GetSegModSegInfo1	0	1
	Resp_Arg	Uint8*	0	255
	RespLen_Arg	Uint8*	8	8
Return Value	Rtn_Cnt_T_u08	Uint8	0	255

Design Rationale

Processing

SegModStdInfo

Function Name	SegModStdInfo	Type	Min	Max
Arguments Passed	Seg_Arg	Uint8	0	255
	Resp_Arg	Uint8*	0	255
	RespLen_Arg	UInt8*	6	6
Return Value	<Hard Coded>	UInt8	1	1

Design Rationale

Processing

SegModAdrMpg

Function Name	SegModAdrMpg	Type	Min	Max
Arguments Passed	Seg_Arg	Uint8	0	255
	MpgIdxInfo_Arg	GetSegModMpgIdx1	0	2
	MpgIdx_Arg	Uint8	0	255
	Resp_Arg	UInt8*	0	4294967295
	RespLen_Arg	Uint8*	8	8
Return Value	Rtn_Cnt_T_u08	Uint8	0	255

Design Rationale

Processing

TunSelnMngt_ChkXcpWrAcs

Function Name	TunSelnMngt_ChkXcpWrAcs	Type	Min	Max
Arguments Passed	ReqAdr_Cnt_T_u32	Uint32	0	4294967296
Return Value	Rtn_Cnt_T_logl	Boolean	FALSE	TRUE

Design Rationale

This function is generated based on the configured access regions in Configurator. Below is just a high level overview of the function. The conditions in the if statements are logically OR’d together to form the tests.

Processing

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1

34.3 - TunSelnMngt_PeerReview

Overview

Summary Sheet
Synergy Project
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES400A_TunSelnMngt_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. 1.2.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. Kevin Smith

Work CR ID:

EA4#7238

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

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci 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:

K. Smith

Review Date :

05/11/17

Lead Peer Reviewer:

Steve H.

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

TunSelnMngt_Cfg_private.c.tt

Source File Revision:

4

Header File Name:

N/A

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

MDD Name:

N/A

Revision:

N/A

FDD/SCIR/DSR/FDR/CM Name:

ES400A_TunSelnMngt_Design

Revision:

1.0.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

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

Yes

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

Yes

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

Yes

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

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.

Yes

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

Yes

Comments:

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

All pointer dereferencing protects against

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

Yes

Comments:

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

All code is mapped with FDD (all FDD

Yes

Comments:

subfunctions and/or model blocks identified

with code comments; all code corresponds to

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

Review did not identify violations of other

Yes

Comments:

coding standard rules

Anomaly or Design Work CR created

Yes

Comments: List Anomaly or CR numbers

for any FDD corrections needed

General Notes / Comments:

Changes were made to the text template that generates a private C file containing flash constants. The Generated files were tested on a local build and in

the test vehicle.

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:

K. Smith

Review Date :

05/11/17

Lead Peer Reviewer:

Steve H.

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

TunSelnMngt.c

Source File Revision:

4

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

1.1.0

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 1

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 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 Analysis

Yes

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:

IdxChgMngt is one point higher then it needs to be

for all functions in the component per Design

and Coding Standards rule [N47]

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:

K. Smith

Review Date :

05/11/17

Lead Peer Reviewer:

Steve H.

Approved by Reviewer(s):

Yes

Other Reviewer(s):

35 - Component Implementation

Component Implementation

Component Documentation

35.1 - XcpIf Integration Manual

Integration Manual

For

XCP Interface (XcpIf)

VERSION: 3.0

DATE: 12-Feb-2018

Prepared By:

Kevin Smith

ESG Software,

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	Approved By
1	Initial version	K. Smith	1.0	6-Jun-15
2	Updates for intial online calibration support	K. Smith	2.0	9-Oct-15
3	Updates for new configuration value	K. Smith	3.0	12-Feb-18

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 7

4.5 Manual Configuration Changes 7

4.6 OS Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

5.4 Other Header Changes 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

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	Process 04.02.00
2	Software Naming Conventions	Process 04.02.00
3	Coding standards	Process 04.02.00
4	FDD	Not available
	<Add if more available>

Dependencies

SWCs

Module	Required Feature
None

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
/Nexteer/EcucDefs_XcpIf/XcpIf/XcpIfCommon/XcpDriverSelection	Integrators should set this to auto detect. However, if the need is there to override the options are available.	XcpIf
/Nexteer/EcucDefs_XcpIf/XcpIf/XcpIfCommon/TunSelnMngtOsApplicationRef	The OS application that holds ES400A.	XcpIf

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

OS Configuration Changes

ApplXcpWrCmn

MTABYTEPTR addr

vuint8 size

const BYTEPTR data

This function should be defined as trusted.

Rte_Call_SetCalPageReq_Oper

This function shall be defined as a non-trusted function call to the application that TunSelnMngt is integrated.

Rte_Call_CopyCalPageReq_Oper

This function shall be defined as a non-trusted function call to the application that TunSelnMngt is integrated.

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

None

Required Global Data Outputs

None

Specific Include Path present

Yes

Other Header Changes

File	Change	Reason
usrostyp.h	Add include statement for CDD_XcpIf.h	The include is needed since for the OS has the function prototypes and datatypes required for the trusted function call.

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
CDD_XcpIfInit	None	Rte

Runnable	Scheduling Requirements	Trigger
Xcp2msDaq	2ms	RTE
CDD_XcpIfPer1	None	100ms

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

The file xcp.cfg needs to have “#define XCP_ENABLE_CALIBRATION_MEM_ACCESS_BY_APPL” added. When the XCP component is generated in GENy, this will enable the application read/write calls.

The #defile XCPIF_MAXCALSEG_CNT_U08 points to a generated value by the Xcp component. Vector currently only allows one segment to be defined. This will have to be manually changed in the xcp.cfg file by the following:

#undef kXcpMaxSegment

#define kXcpMaxSegment XX

XX is the number of tuning groups that are defined in your program.

Optimization Settings

None

Appendix

N/A

35.2 - XcpIf Peer Review Checklists

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
Integration Manual

Sheet 1: Summary Sheet

Rev 1.2

8-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. ES104A_XcpIf_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. 0.0.6

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. K. Smith

Work CR ID:

EA4#20574

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:

Yes

MDD

Yes

Source Code

N/A

PolySpace

Yes

Integration Manual

Yes

Davinci Files

Comments:

Polyspace not available on this component currently. Targeted for version 1.0.0 of the component along with design.

Review checked only the changes to support the new CR 20563 and anomaly 20564

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

No

Comments:

Design has not been completed

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:

K. Smith

Review Date :

02/12/18

Lead Peer Reviewer:

JK Thundathil

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

Yes

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

Yes

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

N/A

Comments:

Not available

match DataDict.m

Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

Change Owner:

K. Smith

Review Date :

02/12/18

Component Type :

SWC

Lead Peer Reviewer:

JK Thundathil

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_XcpIf.c

Source File Revision:

7

Header File Name:

CDD_XcpIf.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. 4

MDD Name:

XcpIf_MDD.docx

Revision:

4

FDD/SCIR/DSR/FDR/CM Name:

N/A

Revision:

N/A

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

For all non-vector related names. Some

names were based from Vector's implementation and do not follow our standards.

for constant names

Yes

Comments:

for function names

Yes

Comments:

See comment for variable names

for other names (component, memory

Yes

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

Yes

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

N/A

Comments:

No design document yet

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:

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

Yes

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

Yes

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

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.

Yes

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

Yes

Comments:

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

All pointer dereferencing protects against

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

Yes

Comments:

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

All code is mapped with FDD (all FDD

Yes

Comments:

subfunctions and/or model blocks identified

with code comments; all code corresponds to

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

Review did not identify violations of other

Yes

Comments:

coding standard rules

Anomaly or Design Work CR created

Yes

Comments: List Anomaly or CR numbers

for any FDD corrections needed

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:

K. Smith

Review Date :

02/12/18

Lead Peer Reviewer:

JK Thundathil

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

XcpIf_MDD.docx

MDD Revision:

4

Source File Name:

CDD_XcpIf.c

Source File Revision:

7

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

Yes

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

Yes

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

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:

K. Smith

Review Date :

02/12/18

Lead Peer Reviewer:

JK Thundathil

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

Yes

Comments:

General Notes / Comments:

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

Change Owner:

K. Smith

Review Date :

02/12/18

Lead Peer Reviewer:

JK Thundathil

Approved by Reviewer(s):

Yes

Other Reviewer(s):

35.3 - XcpIf_MDD

Module Design Document

For

XCP Interface (XcpIf)

VERSION: 4.0

DATE: 12-Feb-2018

Prepared By:

Kevin Smith

EPS Software,

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	Approved By
1	Initial Version	K. Smith	1.0	16-Jun-15
2	Updates for anomaly EA4#6672	K. Smith	2.0	29-Aug-16
3	Updates for change request EA4#8215	K. Smith	3.0	03-Mar-17
4	Updates for CR EA4#20563 anomaly EA4#20564	K. Smith	4.0	12-Feb-18

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 XCP Interface & High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation of XCP Interface 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.2 Initialization Functions 11

7.2.1 CDD_XcpIfInit1 11

7.2.1.1 Design Rationale 11

7.2.1.2 Store Module Inputs to Local copies 11

7.2.1.3 (Processing of function)……… 11

7.2.1.4 Store Local copy of outputs into Module Outputs 11

7.3 PERIODIC FUNCTIONS 11

7.3.1 CDD_XcpIfPer1 11

7.3.1.1 Design Rationale 11

7.3.1.2 Store Module Inputs to Local copies 11

7.3.1.3 (Processing of function)……… 12

7.3.1.4 Store Local copy of outputs into Module Outputs 12

7.3.2 Xcp2msDaq 12

7.3.2.1 Design Rationale 12

7.3.2.2 Store Module Inputs to Local copies 12

7.3.2.3 (Processing of function)……… 12

7.3.2.4 Store Local copy of outputs into Module Outputs 12

7.4 Non PERIODIC FUNCTIONS 12

7.5 Interrupt Functions 12

7.6 Serial Communication Functions 13

7.7 Local Function/Macro Definitions 13

7.8 GLObAL Function/Macro Definitions 14

7.8.1 ApplXcpGetTimestamp 14

7.8.1.1 Description 14

7.8.2 ApplXcpGetPointer 14

7.8.2.1 Description 14

7.8.3 ApplXcpCalibrationWrite 15

7.8.3.1 Description 15

7.8.4 ApplXcpWrCmn 16

7.8.4.1 Description 16

7.8.5 ApplXcpCalibrationRead 16

7.8.5.1 Description 16

7.8.6 ApplXcpCheckWriteAccess 17

7.8.6.1 Description 17

7.8.7 ApplXcpCheckReadAccess 17

7.8.7.1 Description 17

7.8.8 ApplXcpCheckDAQAccess 18

7.8.8.1 Description 18

7.8.9 ApplXcpSetCalPage 19

7.8.9.1 Description 19

7.8.10 ApplXcpGetCalPage 20

7.8.10.1 Description 20

7.8.11 ApplXcpCopyCalPage 21

7.8.11.1 Description 21

7.8.12 ApplXcpUserService 22

7.8.12.1 Description 22

7.8.13 ApplXcpOpenCmdIf 23

7.8.13.1 Description 23

7.8.14 NONTRUSTED_NtWrapS_Rte_Call_CopyCalPageReq_Oper 24

7.8.14.1 Description 24

7.8.15 NONTRUSTED_NtWrapS_Rte_Call_SetCalPageReq_Oper 24

7.8.15.1 Description 24

7.9 TRANSIENT FUNCTIONS 25

8 Unit Test Considerations 26

9 Known Limitations With Design 27

10 Appendix 28

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

Sr. No.	Title	Version
<1>	<MDD Guidelines>	4.0.0
<2>	<Software Naming Conventions>	4.0.0
<3>	<Coding standards>	4.0.0
<4>	<FDD >	Not available
	<Add if more available>

XCP Interface & High-Level Description

XCP Interface provides multiple functions that allow XCP end users and tools to interface with software components contained in the application.

Design details of software module

Graphical representation of XCP Interface

None

Data Flow Diagram

None

Module level DFD

None

Sub-Module level DFD

None

COMPONENT FLOW DIAGRAM

None

Variable Data Dictionary

User defined typedef definition/declaration

Variable definition for enumerated types

Enum Name	Element Name	Value

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value

Global

Constant Name
XcpEventChannel_2ms_DAQ_2

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

CDD_XcpIfInit1

Design Rationale

This function is called at init to enable or disable XCP access.

Store Module Inputs to Local copies

None

(Processing of function)………

Store Local copy of outputs into Module Outputs

None

PERIODIC FUNCTIONS

CDD_XcpIfPer1

Design Rationale

This function is called every 100ms to enable or disable XCP access.

Store Module Inputs to Local copies

None

(Processing of function)………

Store Local copy of outputs into Module Outputs

None

Xcp2msDaq

Design Rationale

This function is called every 2ms for executing the XcpEvent functions for the 2ms DAQ.

Store Module Inputs to Local copies

None

(Processing of function)………

Store Local copy of outputs into Module Outputs

None

Non PERIODIC FUNCTIONS

None

Interrupt Functions

None

Serial Communication Functions

None

Local Function/Macro Definitions

None

GLObAL Function/Macro Definitions

ApplXcpGetTimestamp

Function Name	ApplXcpGetTimestamp	Type	Min	Max
Arguments Passed	None

Return Value	Timestamp_Cnt_T_u32	XcpDaqTimestampType	See description	See description

Description

This function returns the timestamp that is based on a reference timer. The range of return values vary depending on the configuration of the Xcp Component. The data type can range from a full range of a uint8 to a uint32 value.

ApplXcpGetPointer

Function Name	ApplXcpGetPointer	Type	Min	Max
Arguments Passed	addr_ext	vuint8	0	255
	addr	vuint32	1	4294967295
Return Value	RtnAddr_Cnt_T_u32	MTABYTEPTR	1	4294967295

Description

This function takes the extension and address of and returns the physical address of the item.

ApplXcpCalibrationWrite

Function Name	ApplXcpCalibrationWrite	Type	Min	Max
Arguments Passed	addr	MTABYTEPTR	1	4294967295
	size	Vuint8	0	255
	data	BYTEPTR	1	4294967295
Return Value	XCP_CMD_OK	Uint8	0	0

Description

This function calls the common XCP writing function. For this deisgn, the function call will be translated into a trusted function call.

ApplXcpWrCmn

Function Name	ApplXcpWrCmn	Type	Min	Max
Arguments Passed	addr	MTABYTEPTR	1	4294967295
	size	Vuint8	0	255
	data	BYTEPTR	1	4294967295
Return Value	XCP_CMD_OK	Uint8	0	0

Description

This function writes the data passed in by the XCP user to the designated address.

ApplXcpCalibrationRead

Function Name	ApplXcpCalibrationRead	Type	Min	Max
Arguments Passed	addr	MTABYTEPTR	1	4294967295
	size	Vuint8	0	255
	data	BYTEPTR	1	4294967295
Return Value	XCP_CMD_OK	Uint8	0	0

Description

This function reads the data in the designated address and returns it to the XCP user.

ApplXcpCheckWriteAccess

Function Name	ApplXcpCheckWriteAccess	Type	Min	Max
Arguments Passed	addr	MTABYTEPTR	1	4294967295
	Size_Cnt_T_u08	Vuint8	0	255
Return Value	XCP_CMD_OK	Uint8	0	0

Description

This function checks access for XCP writes. Since the functions in tuning selection management handle the presmissions for writes, this function shall always return a positive response.

ApplXcpCheckReadAccess

Function Name	ApplXcpCheckReadAccess	Type	Min	Max
Arguments Passed	addr	MTABYTEPTR	1	4294967295
	Size_Cnt_T_u08	Vuint8	0	255
Return Value	XCP_CMD_OK	Uint8	0	0

Description

This function checks access for XCP reads. Since the functions in tuning selection management handle the presmissions for reads, this function shall always return a positive response.

ApplXcpCheckDAQAccess

Function Name	ApplXcpCheckDAQAccess	Type	Min	Max
Arguments Passed	addr	MTABYTEPTR	1	4294967295
	Size_Cnt_T_u08	Vuint8	0	255
Return Value	XCP_CMD_OK	Uint8	0	0

Description

This function checks access for XCP DAQ access. Since all reads are allowed, this function will also always return a positive response.

ApplXcpSetCalPage

Function Name	ApplXcpSetCalPage	Type	Min	Max
Arguments Passed	Seg_Cnt_T_u08	Vuint8	0	255
	Page_Cnt_T_u08	Vuint8	0	255
	Mod_Cnt_T_u08	Vuint8	0	255
Return Value	Rtn_Cnt_T_u08	Uint8	0	0x28

Description

This function sets the calibration page access. It directly calls the functions used in tuning selection management.

ApplXcpGetCalPage

Function Name	ApplXcpGetCalPage	Type	Min	Max
Arguments Passed	Seg_Cnt_T_u08	Vuint8	0	255
	Mod_Cnt_T_u08	Vuint8	0	255
Return Value	Rtn_Cnt_T_u08	Uint8	0	0x28

Description

This function sets the calibration page access. It directly calls the functions used in tuning selection management.

ApplXcpCopyCalPage

Function Name	ApplXcpCopyCalPage	Type	Min	Max
Arguments Passed	SrcSeg_Cnt_T_u08	Vuint8	0	255
	SrcPage_Cnt_T_u08	Vuint8	0	255
	DestSeg_Cnt_T_u08	Vuint8	0	255
	DestPage_Cnt_T_u08	Vuint8	0	255
Return Value	XCP_CMD_OK	Uint8	0	0x28

Description

This function sets the calibration page access. It directly calls the functions used in tuning selection management.

ApplXcpUserService

Function Name	ApplXcpUserService	Type	Min	Max
Arguments Passed	pCmd	BYTEPTR	0	4294967295
Return Value	XCP_CMD_OK	Uint8	0	0x3

Description

This function handles user service requests.

ApplXcpOpenCmdIf

Function Name	ApplXcpOpenCmdIf	Type	Min	Max
Arguments Passed	pCmd	BYTEPTR	0	4294967295
	pRes	BYTEPTR	0	4294967295
	pLength	BYTEPTR	0	4294967295
Return Value	XCP_CMD_OK	Uint8	0	0x3

Description

This function handles XCP service requests that are not supported by the driver but defined by the XCP protocol specification.

NONTRUSTED_NtWrapS_Rte_Call_CopyCalPageReq_Oper

Function Name	NONTRUSTED_NtWrapS_Rte_Call_CopyCalPageReq_Oper	Type	Min	Max
Arguments Passed	FunctionIndex	NonTrustedFunctionIndexType	0	65535
	FunctionParams	NonTrustedFunctionParameterRefType	N/A	N/A
Return Value	N/A	N/A	N/A	N/A

Description

NONTRUSTED_NtWrapS_Rte_Call_SetCalPageReq_Oper

Function Name	NONTRUSTED_NtWrapS_Rte_Call_SetCalPageReq_Oper	Type	Min	Max
Arguments Passed	FunctionIndex	NonTrustedFunctionIndexType	0	65535
	FunctionParams	NonTrustedFunctionParameterRefType	N/A	N/A
Return Value	N/A	N/A	N/A	N/A

Description

TRANSIENT FUNCTIONS

None

Unit Test Considerations

The value datatype of XcpDaqTimestampType can be uint8, uint16, or uint32 depending on the configuration of XCP. Unit testing shall test full ranges for all three types to ensure proper functionality.

Known Limitations With Design

There are no protections in this design for executing on NULL_PTRs

Appendix

None