System Function (Applicative Software)

3 Assi & High-Level Description 7

4.1 Graphical representation of Assi 8

7.2 Initialization Functions 11

7.3 PERIODIC FUNCTIONS 11

7.3.1 Per: Assiper1 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 Non PERIODIC FUNCTIONS 11

7.5 Interrupt Functions 11

7.6 Serial Communication Functions 12

7.7 Local Function/Macro Definitions 12

7.8 GLObAL Function/Macro Definitions 12

7.9 TRANSIENT FUNCTIONS 12

8 Unit Test Considerations 13

9 Known Limitations With Design 14

10 NoneAppendix 15

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 4.00.00
<2>	<Software Naming Conventions>	Process 4.00.00
<3>	<Coding standards>	Process 4.00.00
<4>	FDD - SF001A_Assi_Design	See Synergy Subproject version
	<Add if more available>

Assi & High-Level Description

Refer FDD

Design details of software module

Graphical representation of Assi

Data Flow Diagram

Module level DFD

Sub-Module level DFD

COMPONENT FLOW DIAGRAM

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	<(Variable name qualified Refer[2])>	<Define the value >

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

< All program specific constants will be defined in detail >

Local

Constant Name	Resolution	Units	Value
Refer constants from .m file

Global

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

Constant Name

Refer constants from .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 .m file

Software Module Implementation

Sub-Module Functions

NONE

Initialization Functions

None

PERIODIC FUNCTIONS

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

Per: Assiper1

Design Rationale

Fault Injection client call is conditional compiled based on “FLTINJENA” build constant.

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

Local Function/Macro Definitions

None

GLObAL Function/Macro Definitions

None

TRANSIENT FUNCTIONS

Unit Test Considerations

None

Known Limitations With Design

Appendix

1.3 - Assi_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. SF001A_Assi_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. SF001A_Assi_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. Shawn Penning

Work CR ID:

EA4#11410

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

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 :

05/10/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Shruthi Raghavan

Brionna Spencer

Avinash James

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

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

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 :

05/10/17

Component Type :

Application

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Shruthi Raghavan

Brionna Spencer

Avinash James

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

Assi.c

Source File Revision:

6

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:

Assi_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

SF001A_Assi_Design

Revision:

1.5.0

Quality Check Items:

Rationale is required for all answers of No

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 tags removed per requirement and csv file deleted.

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 :

05/10/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Shruthi Raghavan

Brionna Spencer

Avinash James

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

Assi.c

Source File Revision:

6

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

Yes

Comments:

comments still appropriate

Updated 16.10 deviation comments

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 :

05/10/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Shruthi Raghavan

Brionna Spencer

Avinash James

2 - Component Implementation

Component Implementation

Component Documentation

2.1 - AssiHiFrq_Integration_Manual

Integration Manual

For

SF028A AssiHiFrq

VERSION: 1.0

DATE: 05-AUG-2015

Prepared By:

Kathleen Creager

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

Description	Author	Version	Date
Initial version	Kathleen Creager	1.0	05-Aug-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 AssiHiFrq High-Level Description 4

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

Ref #	Title	Version
1	EA4 Software Naming Conventions.doc	01.00.00
2	Software Design and Coding Standards.doc	2.1
3	SF028A_AssiHiFrq_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
AssiHiFrqInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
AssiHiFrqPer1	None	RTE 2 ms

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
AssiHiFrq_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>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

<Define all the preprocessor Macros needed and conditions when needed>.

Optimization Settings

<Define Optimization levels that are needed and conditions when needed>.

Appendix

<This section is for appendix>

2.2 - AssiHiFrq_MDD

Module Design Document

For

AssiHiFrq

February 15, 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	Kathleen Creager	01.00.00	04-Aug-2015
Updated per design vers. 1.1.0	Matthew Leser	2.0	09-Feb-2017
Updated to include Unit Test Consideration	Matthew Leser	3.0	15-Feb-2017

Table of Contents

2.1 Graphical representation of AssiHiFrq 5

4.1 Sub-Module Functions 7

4.1.1 Init: AssiHiFrqInit1 7

4.1.1.1 Design Rationale 7

4.1.1.2 Module Outputs 7

4.1.2 Per: AssiHiFrqPer1 7

4.1.2.1 Design Rationale 7

4.1.2.2 Store Module Inputs to Local copies 7

4.1.2.3 (Processing of function)……… 7

4.1.2.4 Store Local copy of outputs into Module Outputs 7

4.2 Server Runables 7

4.3 Interrupt Functions 8

4.4 Module Internal (Local) Functions 8

4.5 GLOBAL Function/Macro Definitions 8

5 Known Limitations with Design 9

6 UNIT TEST CONSIDERATION 10

Summary Sheet
Synergy Project
MDD

AssiHiFrq High-Level Description

Implements the SF028A_AssiHiFrq_Design FDD. This function provides a means of compensating for system

inertia and road feedback. It is tunable over both vehicle speed and handwheel torque to obtain the desired

level of disturbance rejection under various operating conditions. It passes handwheel torque through a high-pass

filter and multiplies the resulting signal by a tunable gain factor. The output is known as high-frequency assist

and is simply added to the usual assist calculated elsewhere

Design details of software module

Graphical representation of AssiHiFrq

Data Flow Diagram

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
None	<Refer MDD guidelines [1]>	<Refer MDD guidelines [1]>	<Refer MDD guidelines [1]>

Software Component Implementation

Sub-Module Functions

Init: AssiHiFrqInit1

Design Rationale

Init function is present in DataDict.m file but not shown in FDD model, and no initialization logic is needed. This is implemented as an empty function.

Module Outputs

None

Per: AssiHiFrqPer1

Design Rationale

FDD model does not contain a block named AssiHiFrqPer1; this function implements the AssiHiFrq block.

BilnrIntrpnWithRound_u16_u16MplXu16MplY function from NxtrIntrpn library used to implement the 2-D Lookup tables in the SF028A_AssiHiFrq/AssiHiFrq/AssiHiFrq/Determine Gain model block.

Blnd_f32 function from NxtrMath library used to implement the part of the model that computes GainVal_MtrNmpHwNm from the outputs of the three bilinear interpolation functions in the SF028A_AssiHiFrq/AssiHiFrq/AssiHiFrq/Determine Gain model block.

FilHpUpdGain and FilHpUpdOutp_f32 functions from the NxtrFil library used to implement HP-CF Filter block in the SF028A_AssiHiFrq/AssiHiFrq/AssiHiFrq model block.

A note in the model mentions that the frequency lookup table for the high pass filter cutoff frequency could be converted to the filter gain values at initialization. This was not done because the DataDict.m file did not contain the necessary IRV for the converted table, and the FilHpUpdGain library function expects frequency in Hz; if this throughput improvement (converting the frequency table once in initialization) is made in the future, a new version of FilHpUpdGain will be needed.

LnrIntrpn_u16_u16VariXu16VariY function from NxtrIntrpn library used to implement the “freq lookup” block in the SF028A_AssiHiFrq/AssiHiFrq/AssiHiFrq model block.

Store Module Inputs to Local copies

See FDD

(Processing of function)………

See FDD, and design rationale noted above.

Store Local copy of outputs into Module Outputs

See 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

PIL Testers: Do not use MIL vectors which have input signals outside the range +/- one billion because these vectors are not per the current MIL test guidelines.

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	SF028A_AssiHiFrq_Design	See Synergy subproject version

2.3 - AssiHiFrq_Review

Overview

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

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

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

N/A

Source Code

N/A

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

Changes were only made to MDD

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 :

02/15/17

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Sheet 3: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

AssiHiFrq_MDD.docx

MDD Revision:

3

Source File Name:

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

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:

Matthew Leser

Review Date :

02/15/17

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

3 - Component Implementation

Component Implementation

Component Documentation

3.1 - AssiPahSum_IntegrationManual

Integration Manual

For

AssiPahSum

VERSION: 1.0

DATE: 07-Jul-2015

Prepared By:

Nick Saxton,

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	07-Jul-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 AssiPahSum & High-Level Description 4

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 – SF034B Assist Path Summation	See Synergy subproject version
2	Software Naming Conventions	Process 4.01.0
3	Software Design and Coding Standards	Process 4.01.0

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
None

Runnable	Scheduling Requirements	Trigger
AssiPahSumPer1	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
<Memmap usuage info>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

3.2 - AssiPahSum_MDD

Module Design Document

For

AssiPahSum

July 07, 2015

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Nick Saxton,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	N. Saxton	1.00.00	07-Jul-2015

Table of Contents

2.1 Graphical representation of AssiPahSum 5

4.1.1 Sub-Module Functions 7

4.1.2 Interrupt Service Routines 7

4.1.3 Server Runnable Functions 7

4.1.4 Module Internal (Local) Functions 7

4.1.5 Transition Functions 7

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

AssiPahSum & High-Level Description

This function merges command signals and is meant for use in vehicle programs that do not need the extra features of the SF034A firewall function.

Design details of software module

Graphical representation of AssiPahSum

Data Flow Diagram

Component level DFD

N/A

Function level DFD

N/A

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

None

Software Component Implementation

Sub-Module Functions

Initialization sub-module {_Init()}

None

Periodic sub-module {_Per()}

AssiPahSumPer1

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

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

None

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 (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 – SF034B Assist Path Summation	See Synergy subproject version

3.3 - AssiPahSum_Peer_Review_Checklist

Overview

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

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. SF034B_AssiPahSum_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#11059

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

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 :

05/19/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Shruthi Raghavan

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

Application data types removed

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

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 :

05/19/17

Component Type :

Application

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Shruthi Raghavan

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

AssiPahSum.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:

AssiPahSum_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF034B_AssiPahSum_Design

Revision:

1.0.0

Quality Check Items:

Rationale is required for all answers of No

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

tags were 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 :

05/19/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Shruthi Raghavan

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

AssiPahSum.c

Source File Revision:

2

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

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 :

05/19/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Shruthi Raghavan

4 - Component Implementation

Component Implementation

Component Documentation

4.1 - AssiSumLim_Integration Manual

Integration Manual

For

‘AssiSumLim’

VERSION: 1.0

DATE: 04-June-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	22-May-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 – SF004B_AssiSumLim_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
AssiSumLimInit1	None	Init

AssiSumLimPer1

SetManTqCmd_Oper

None

2ms

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
None

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None

Appendix

None

4.2 - AssiSumLim_MDD

Module Design Document

For

‘AssiSumLim’

VERSION: 3.0

DATE: 15-May-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	03-Jun-2015
2	Updated Graph , added Limitations, Updated Server Runnable Information	Matthew Leser	2.0	15-May-2017
3	Removed application data types; PIM range correction noted	Shawn Penning	3.0	14-Jun-2017

Table of Contents

3 AssiSumLim High-Level Description 7

4.1 Graphical representation of AssiSumLim 8

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

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

6.1.2 Module specific Lookup Tables Constants 11

7 Software Module Implementation 12

7.1 Sub-Module Functions 12

7.1.1 Initialization Functions 12

7.1.1.1 INIT: AssiSumLimInit1 12

7.1.1.1.1 Design Rationale 12

7.1.1.1.2 Module Outputs 12

7.1.1.1.3 Module Internal 12

7.1.2 PERIODIC FUNCTIONS 12

7.1.2.1 Per: AssiSumLimPer1 12

7.1.2.1.1 Design Rationale 12

7.1.2.1.2 Store Module Inputs to Local copies 12

7.1.2.1.3 (Processing of function)……… 12

7.1.2.1.4 Store Local copy of outputs into Module Outputs 12

7.1.3 Interrupt Functions 12

7.1.4 Server runnables 13

7.1.4.1 SetManTqCmd 13

7.1.4.1.1 Design Rationale 13

7.1.4.1.2 Store Module Inputs to Local copies 13

7.1.4.1.3 (Processing of function)……… 13

7.1.4.1.4 Store Local copy of outputs into Module Outputs 13

7.1.5 Local Function/Macro Definitions 13

7.1.5.1 Local Function #1 13

7.1.5.1.1 Description 13

7.1.5.2 Local Function #2 13

7.1.5.2.1 Description 13

7.1.6 GLObAL Function/Macro Definitions 13

7.1.7 Tranisition FUNCTIONS 13

8 Known Limitations With Design 14

9 UNIT TEST CONSIDERATION 15

10 Appendix 16

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	MDD Guidelines	Process 3.06.00
2	Software Naming Conventions	2.0
3	Software Design and Coding standards	2.1
4	FDD - SF004B_AssiSumLim_Design	See Synergy sub project version

AssiSumLim High-Level Description

Design details of software module

Graphical representation of AssiSumLim

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

Note: Refer .m file for constants definitions.

Global

Constant Name
None

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
None

Software Module Implementation

Sub-Module Functions

Initialization Functions

AssiSumLimInit1

INIT: AssiSumLimInit1

Design Rationale

Design follows implemenetation in FDD.

Module Outputs

Refer ‘AssiSumLimInit1’ block in FDD

Module Internal

None

PERIODIC FUNCTIONS

Per: AssiSumLimPer1

Design Rationale

Design follows implementation in FDD.

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD (Block ‘AssiSumLmtPer1’)

Store Local copy of outputs into Module Outputs

Refer to FDD

Interrupt Functions

None

Server runnables

SetManTqCmd

Function Name	SetManTqCmd_Oper	Type	Min		Max
Arguments Passed	VehSpd_Kph_T_f32	float32	0.0F	511.0F
	ManTqCmd	float32	-8.8	8.8
	ManTqCmdEna	boolean	FALSE	TRUE
Return Value	ManTqCmdRtn_Uls_T_enum	Std_ReturnType	0	1

Design Rationale

Argument names should have _arg added to end of names for ManTqCmd and ManTqCmdEna.

Store Module Inputs to Local copies

None

(Processing of function)………

Refer ‘SetManTqCmd’ block in FDD

Store Local copy of outputs into Module Outputs

None

Local Function/Macro Definitions

None

GLObAL Function/Macro Definitions

None

Tranisition FUNCTIONS

None

Known Limitations With Design

.

Tustin Filter does not have a library block in design or code (could be added to component after CR EA4#6619 is completed).

SetNtcSts.CallLocation should include AssiSumLimInit1 in DataDict.m (see CR EA4#12283).

Range for MotVelFilLp is incorrect and could cause overflow. Should be max of 1350, not 62500. This will be addressed in future design with CR EA4#12743.

UNIT TEST CONSIDERATION

None

Appendix

None

4.3 - AssiSumLim_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. SF004B_AssiSumLim_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. SF004B_AssiSumLim_Impl_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. Matthew Leser

Work CR ID:

EA4#17570

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:

Approval given by Steve to deviate from Review Process by not inviting others due to Program Timing.

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/16/17

Lead Peer Reviewer:

Steven Horwath

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:

AssiSumLim.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:

AssiSumLim_MDD.docx

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

SF004B_AssiSumLim_Design

Revision:

2.2.0

Quality Check Items:

Rationale is required for all answers of No

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

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:

Matthew Leser

Review Date :

11/16/17

Lead Peer Reviewer:

Steven Horwath

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:

AssiSumLim.c

Source File Revision:

5

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

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:

Matthew Leser

Review Date :

11/16/17

Lead Peer Reviewer:

Steven Horwath

Approved by Reviewer(s):

Yes

Other Reviewer(s):

5 - Component Implementation

Component Implementation

Component Documentation

5.1 - CmplncErr_IntegrationManual

Integration Manual

For

Compliance Error

VERSION: 1.0

DATE: 11-JAN-2016

Prepared By:

Kannappa Chidambaram,

Tata Elxsi, INDIA

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Kannappa Chidambaram P R	1.0	01/11/2016

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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

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

Please refer DataDict.m file.

Required Global Data Outputs

Please refer DataDict.m file.

Specific Include Path present

NA

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
CmplncErrInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
CmplncErrPer1	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.

5.2 - CmplncErr_MDD

Module Design Document

For

CmplncErr

Prepared For:

,

Prepared By:

Kannappa Chidambaram,

Tata Elxsi, INDIA

Change History

Sl. No.	Description	Author	Version	Date
1	Initial version	Kannappa Chidambaram P R	1.0	01/11/2016

Table of Contents

2 CmplncErr & High-Level Description 5

3.1 Graphical representation of CmplncErr 6

5.1.1 Init: CmplncErrInit1 8

5.1.2 Per: CmplncErrPer1 8

5.2 Server Runnable 8

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

Introduction

Purpose

CmplncErr & High-Level Description

Please refer FDD

Design details of software module

Graphical representation of CmplncErr

Data Flow Diagram

Please refer FDD

Component level DFD

Please refer FDD.

Function level DFD

Please refer FDD.

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Please refer .m file

Software Component Implementation

Sub-Module Functions

Init: CmplncErrInit1

Design Rationale

None

Module Outputs

None

Per: CmplncErrPer1

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Please refer FDD

Store Local copy of outputs into Module Outputs

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

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	Process 4.02.00
4	Software Design and Coding Standards.doc	Process 4.02.00
5	FDD: SF041A_ CmplncErr_Design	See Synergy sub project version

5.3 - CmplncErr_Review

Review_Checklist

Overview

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. SF041A_CmplncErr_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. SF041A_CmplncErr_Impl_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. Kannappa Chidambaram (Tata Elxsi)

Work CR ID:

EA4#2701

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 :

01/25/16

Lead Peer Reviewer:

Sankardu V

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

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

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:

Kannappa Chidambaram, Krishna Anne

Review Date :

20-Jan-16

Component Type :

Application

Lead Peer Reviewer:

Sankardu V

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sudeep Shankar

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CmplncErr.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:

CmplncErr_MDD

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF041A_CmplncErr_Design

Revision:

1.1.0

Quality Check Items:

Rationale is required for all answers of No

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:

Use of explicit typecasting of uint16 type variable to sint32 type suppress the QAC 10.1 rule

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

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

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

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:

Kannappa Chidambaram, Krishna Anne

Review Date :

21-Jan-16

Lead Peer Reviewer:

Sankardu V

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sudeep Shankar

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

CmplncErr_MDD

MDD Revision:

1

Source File Name:

CmplncErr.c

Source File Revision:

1

Source File Name:

NA

Source File Revision:

Source File Name:

NA

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:

Kannappa Chidambaram, Krishna Anne

Review Date :

21-Jan-16

Lead Peer Reviewer:

Sankardu V

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sudeep Shankar

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CmplncErr.c

Source File Revision:

1

Source File Name:

NA

Source File Revision:

Source File Name:

NA

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

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:

Kannappa Chidambaram, Krishna Anne

Review Date :

21-Jan-16

Lead Peer Reviewer:

Sankardu V

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sudeep Shankar

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

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:

Kannappa Chidambaram, Krishna Anne

Review Date :

21-Jan-16

Lead Peer Reviewer:

Sankardu V

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sudeep Shankar

5.4 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
SF041A	51	CmplncErr.c	CmplncErrPer1	264	I
SF041A	39	CmplncErr.c	CmplncErrPer1	262,264	I
SF041A	38	CmplncErr.c	CmplncErrPer1	256	I
SF041A	48	CmplncErr.c	CmplncErrPer1	264	I
SF041A	49	CmplncErr.c	CmplncErrPer1	250	I
SF041A	54	CmplncErr.c	CmplncErrPer1	234	I
SF041A	57	CmplncErr.c	CmplncErrPer1	234	I
SF041A	56	CmplncErr.c	CmplncErrPer1	234	I
SF041A	42	CmplncErr.c	CmplncErrPer1	262,264	I
SF041A	36	CmplncErr.c	CmplncErrPer1	234	I
SF041A	40	CmplncErr.c	CmplncErrPer1	234	I
SF041A	41	CmplncErr.c	CmplncErrPer1	262,264	I
SF041A	35	CmplncErr.c	CmplncErrPer1	240	I
SF041A	62	CmplncErr.c	CmplncErrPer1	250	I
SF041A	63	CmplncErr.c	CmplncErrPer1	224,228	I
SF041A	64	CmplncErr.c	CmplncErrPer1	262	I
SF041A	65	CmplncErr.c	CmplncErrPer1	222,245	I
SF041A	66	CmplncErr.c	CmplncErrPer1	264	I
SF041A	47	CmplncErr.c	CmplncErrPer1	262	I
SF041A	52	CmplncErr.c	CmplncErrPer1	262	I
SF041A	53	CmplncErr.c	CmplncErrPer1	250	I

6 - Component Implementation

Component Implementation

Component Documentation

6.1 - Dampg_IntegrationManual

Integration Manual

For

Dampg

VERSION: 1.0

DATE: 01-July-2015

Prepared By:

Sankardu Varadapureddi,

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	01-July-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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
v	FDD – SF003A_Dampg_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
DampgInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
DampgPer1	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

6.2 - Dampg_MDD

Module Design Document

For

Dampg

July 1, 2015

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Sankardu Varadapureddi,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Sankardu Varadapureddi	1.0	01-July-2015

Table of Contents

2 Dampg High-Level Description 5

3.1 Graphical representation of <Component Name> 6

5.1.1 Sub-Module Functions 9

5.1.2 Interrupt Service Routines 9

5.1.3 Server Runnable Functions 9

5.1.4 Module Internal (Local) Functions 9

5.1.4.1 Local Function #1 9

5.1.4.2 Description 9

5.1.4.3 Local Function #2 9

5.1.4.4 Description 9

5.1.5 Transition Functions 10

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Introduction

Purpose

Scope

Dampg High-Level Description

Refer to FDD

Design details of software module

Graphical representation of Dampg

Data Flow Diagram

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

None

Software Component Implementation

Sub-Module Functions

Initialization sub-module {_Init()}

DampgInit1 (Refer FDD for details)

Periodic sub-module {_Per()}

DampgPer1 (Refer FDD for details)

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	MotVelDampgCmd	Type	Min	Max
Arguments Passed	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
	HwTq_HwNwtMtr_T_f32	float32	-10	10
	TSca_Uls_T_f32	float32	0	10
	VehSpd_Kph_T_f32	float32	0	511
Return Value	ActvDampg_MotNwtMtr_T_f32	float32	-176	176

Description

‘MotVelDampgCmd’ block implementation.

Local Function #2

Function Name	HydPwrSteerDampgCmd	Type	Min	Max
Arguments Passed	VehSpd_Kph_T_f32	float32	0	511
	TSca_Uls_T_f32	float32	0	10
	AssiCmdBas_MotNwtMtr_T_f32	float32	-8.8	8.8
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
Return Value	HydDampg_MotNwtMtr_T_f32	float32	-8.8	8.8

Description

‘HydPwrSteerDampgCmd’ block implementation.

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	1.0
4	Software Design and Coding Standards.doc	2.0
5	FDD - SF003A_Dampg_Design	See Synergy sub project version

6.3 - Dampg_Peer_Review_Checklist

Overview

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. SF003A_Dampg_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. SF003A_Dampg_Impl_1.7.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#11359

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 :

05/26/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

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

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

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

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 :

05/26/17

Component Type :

Application

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

Dampg.c

Source File Revision:

7

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:

Dampg_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF003A_Dampg_Design

Revision:

1.4.0

Quality Check Items:

Rationale is required for all answers of No

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:

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 :

05/26/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

Dampg.c

Source File Revision:

7

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

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 :

05/26/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

7 - Component Implementation

Component Implementation

Component Documentation

7.1 - DampgPahSum_IntegrationManual

Integration Manual

For

DampgPahSum

VERSION: 1.0

DATE: 07-Jul-2015

Prepared By:

Nick Saxton,

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	07-Jul-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 DampgPahSum & High-Level Description 4

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 – SF035B Damping Path Summation	See Synergy subproject version
2	Software Naming Conventions	Process 4.01.0
3	Software Design and Coding Standards	Process 4.01.0

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
None

Runnable	Scheduling Requirements	Trigger
DampgPahSumPer1	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
<Memmap usuage info>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

7.2 - DampgPahSum_MDD

Module Design Document

For

DampgPahSum

July 07, 2015

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Nick Saxton,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	N. Saxton	1.00.00	07-Jul-2015

Table of Contents

2.1 Graphical representation of DampgPahSum 5

4.1.1 Sub-Module Functions 7

4.1.2 Interrupt Service Routines 7

4.1.3 Server Runnable Functions 7

4.1.4 Module Internal (Local) Functions 7

4.1.5 Transition Functions 7

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

DampgPahSum & High-Level Description

This function calculates the damping command by taking the difference of the base damping and inertia compensation and is intended for use in programs that do not require the extra features of SF035A.

Design details of software module

Graphical representation of DampgPahSum

Data Flow Diagram

Component level DFD

N/A

Function level DFD

N/A

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

None

Software Component Implementation

Sub-Module Functions

Initialization sub-module {_Init()}

None

Periodic sub-module {_Per()}

DampgPahSumPer1

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

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

None

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 (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 – SF035B Damping Path Summation	See Synergy subproject version

7.3 - DampgPahSum_Peer_Review_Checklist

Overview

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. SF035B_DampgPahSum_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. SF035B_DampgPahSum_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#11061

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 :

05/26/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

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

N/A

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

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 :

05/26/17

Component Type :

Application

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

DampgPahSum.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:

DampPahSum_MDD.doc

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF035B_DampgPahSum_Design

Revision:

1

Quality Check Items:

Rationale is required for all answers of No

Summary Sheet
Synergy Project
Source Code
PolySpace

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 :

05/26/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

DampgPahSum.c

Source File Revision:

2

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

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 :

05/26/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

8 - Component Implementation

Component Implementation

Component Documentation

8.1 - DrvrTqEstimn_ Peer Review Checklists

Overview

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. SF056A_DrvrTqEstimn_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. SF056A_DrvrTqEstimn_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#12871

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 :

07/27/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

Brendon Binder

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

DrvrTqEstimn.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:

DrvrTqEstimn_MDD

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF056A_DrvrTqEstimn_Design

Revision:

1.0.2

Quality Check Items:

Rationale is required for all answers of No

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

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

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,

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:

Review Date :

Lead Peer Reviewer:

Approved by Reviewer(s):

Other Reviewer(s):

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

DrvrTqEstimn.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 8.1.1-R

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

11.5 and 12.12 Deviation comments removed because they did not apply

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:

Review Date :

Lead Peer Reviewer:

Approved by Reviewer(s):

Other Reviewer(s):

8.2 - DrvrTqEstimn_Integration Manual

Integration Manual

For

DrvrTqEstimn

VERSION: 1.0

DATE: 01-Feb-2017

Prepared By:

Matthew Leser

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Matthew Leser	1.0	01-FEB-2017

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 : SF056A_DrvrTqEstimn_Design	See Synergy Sub Project Version
2	Software Naming Conventions	1.0
3	Software Design and Coding Standards	2.1

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 in the FDD

Required Global Data Outputs

Refer DataDict.m file in the FDD

Specific Include Path present

None

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
DrvrTqEstimnInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
DrvrTqEstimnPer1	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.

8.3 - DrvrTqEstimn_MDD

Module Design Document

For

DrvrTqEstimn

Feb 2, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Matthew Leser

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	Matthew Leser	1.0	02-Feb-2017

Table of Contents

2 DrvrTqEstimn & High-Level Description 5

3.1 Graphical representation of DrvrTqEstimn 6

5.1.1 Init: DrvrTqEstimnInit1 8

5.1.2Per: DrvrTqEstimnPer1 8

5.1.1.2 Module Outputs 8

5.1.1.3 Design Rationale 8

5.1.1.4 Store Module Inputs to Local copies 8

5.1.1.5 (Processing of function)……… 8

5.1.1.6 Store Local copy of outputs into Module Outputs 8

5.2 Server Runnables 8

5.4.1.1 Design Rationale 8

5.4.1.2 Processing 8

Introduction

Purpose

MDD for Driver Torque Estimation.

DrvrTqEstimn & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation of DrvrTqEstimn

Data Flow Diagram

Component level DFD

Please refer FDD.

Function level DFD

Please refer FDD.

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Please refer Data Dictionary .m file	NA	NA	NA

Software Component Implementation

Sub-Module Functions

5.1.1 Init: DrvrTqEstimnInit1

Design Rationale

None

Module Outputs

None

5.1.2Per: DrvrTqEstimnPer1

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Please refer FDD

Store Local copy of outputs into Module Outputs

Please refer FDD

Server Runnables

None

Interrupt Functions

None

Module Internal (Local) Functions

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	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD : SF056A_DrvrTqEstimn_Design	See Synergy Sub-project version

9 - Component Implementation

Component Implementation

Component Documentation

9.1 - DualCtrlrOutpMgr_IntegrationManual

Integration Manual

For

DualCtrlrOutpMgr

VERSION: 1.0

DATE: 18-OCT-2017

Prepared By:

Shawn Penning,

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Description	Author	Version	Date
Initial version	Shawn Penning	1.0	18-Oct-2017

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 DualCtrlrOutpMgr High-Level Description 4

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.doc	01.00.00
2	Software Design and Coding Standards.doc	2.1
3	SF062B_ DualCtrlrOutpMgr_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
DualCtrlrOutpMgrInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
DualCtrlrOutpMgrPer1	None	RTE(2ms)
DualCtrlrOutpMgrPer2	None	RTE(10ms)

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

9.2 - DualCtrlrOutpMgr_MDD

Module Design Document

For

DualCtrlrOutpMgr

18-Oct-2017

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	Shawn Penning	1.0	18-Oct-2017

Table of Contents

2.1 Graphical representation of DualCtrlrOutpMgr 5

4.1 Sub-Module Functions 7

4.1.1 Init: DualCtrlrOutpMgrInit1 7

4.1.1.1 Design Rationale 7

4.1.1.2 Module Outputs 7

4.1.2 Init: DualCtrlrOutpMgrPer1 7

4.1.2.1 Design Rationale 7

4.1.2.2 Module Outputs 7

4.2 Server Runables 7

4.3 Interrupt Functions 7

4.3.1 Interrupt Function Name 7

4.4 Module Internal (Local) Functions 8

4.4.1 Local Function #1 8

4.4.1.1 Design Rationale 8

4.4.1.2 Processing 8

4.5 GLOBAL Function/Macro Definitions 8

5 Known Limitations with Design 9

6 UNIT TEST CONSIDERATION 10

Appendix C Please references 13

DualCtrlrOutpMgr High-Level Description

Refer to FDD

Design details of software module

Refer to FDD

Graphical representation of DualCtrlrOutpMgr

Data Flow Diagram

Refer to FDD

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
Refer to .m file for constants

Software Component Implementation

Sub-Module Functions

Init: DualCtrlrOutpMgrInit1

Design Rationale

Refer to FDD

Module Outputs

None

Per1: DualCtrlrOutpMgrPer1

Design Rationale

Refer to FDD.

ElapsedTimeFlag function is used to avoid the repetitive code and make optimization.

Module Outputs

None

Per2: DualCtrlrOutpMgrPer2

Design Rationale

Refer to FDD.

ElapsedTimeFlag function is used to avoid the repetitive code and make optimization.

Module Outputs

None

Server Runables

None

Interrupt Functions

None

Interrupt Function Name

None

Module Internal (Local) Functions

Local Function #1

Function Name	ElapsedTimeFlag	Type	Min	Max
Arguments Passed	PrmTmrThd_Cnt_T_u16	uint16	0U	1000
	FltStsFlag1_Cnt_T_logl	boolean	FALSE	TRUE
	*PimFlag_Cnt_T_logl	boolean	FALSE	TRUE
	*PimTmr_Cnt_T_u32	uint32	0U	4294967295U
	PimFlgPrev_Cnt_T_logl	boolean	FALSE	TRUE
	*OutpFlg_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	NA	NA	NA	NA

Design Rationale

Implementation of 'ElapsedTimeX' block (X=1,2,3 etc).

Processing

Please refer 'ElapsedTimeX' block (X=1,2,3 etc).

Local Function #2

Function Name	Andoper	Type	Min	Max
Arguments Passed	ImcDualMotCtrlMtgtnEnaVld_Cnt_T_logl	boolean	FALSE	TRUE
	ImcDualMotCtrlMtgtnEna_Cnt_T_logl	boolean	FALSE	TRUE
Return Value		boolean	FALSE	TRUE

Design Rationale

Implementation of 'Andoper' block (X=1,2,3 etc).

Processing

Please refer ‘Andoper' block (X=1,2,3 etc).

Local Function #3

Function Name	Decoder	Type	Min	Max
Arguments Passed	MotAndThermProtnLoaMod_Cnt_T_u08	uint8	0U	1000
Return Value		boolean	FALSE	TRUE

Design Rationale

Implementation of 'Decoder' block (X=1,2,3 etc).

Processing

Please refer 'Decoder' block (X=1,2,3 etc).

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

Please 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: SF062B_DualCtrlrOutpMgr_Design	See Synergy subproject version

9.3 - DualCtrlrOutpMgr_PeerReview

Overview

Summary Sheet
Davinci Files
Source Code
MDD
PolySpace
Integration Manual
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. SF062B_DualCtrlrOutpMgr_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. SF062B_DualCtrlrOutpMgr_Impl_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. Shawn Penning

Work CR ID:

EA4#15146

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

Initial Version

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

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 :

11/09/17

Component Type :

Application

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

Brendon Binder

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

DualCtrlrOutpMgr.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:

DualCtrlrOutpMgr_MDD

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF062A_DualCtrlrOutpMgr_Design

Revision:

1.0.0

Quality Check Items:

Rationale is required for all answers of No

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace
help
Version History

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

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

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/09/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

Brendon Binder

Sheet 4: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

DualCtrlrOutpMgr_MDD

MDD Revision:

1

Source File Name:

DualCtrlrOutpMgr.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:

Krishna Anne

Review Date :

11/09/17

Lead Peer Reviewer:

Krishna Anne

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:

DualCtrlrOutpMgr.c

Source File Revision:

1

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

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 :

11/09/17

Lead Peer Reviewer:

Krishna Anne

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

No

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:

Shawn Penning

Review Date :

11/09/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

11/09/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

10 - Component Implementation

Component Implementation

Component Documentation

10.1 - DutyCycThermProtn_DesignReview

Overview

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

DutyCycThermProtn

Revision / Baseline:

SF009A_DutyCycThermProtn_Impl_4.1.0

Change Owner:

Matthew Leser

Work CR ID:

EA4#19215

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

Yes

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

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

0.5

0

Component developer reviewers:

0

0.5

0

1

Other reviewers:

0

1

0

Total hours

0

2

0

2

Content reviewed

Lines of code:

27

Elements of .arxml content:

0

Pages of documentation:

3

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:

Change Owner:

Matthew Leser

Review Date :

04/05/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Mrudula

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

Sheet 3: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

DutyCycThermProtn.c

Source File Revision:

10

Header File Name:

Header File Revision:

MDD Name:

DutyCycThermProtn_MDD.docx

6

SWC Design Name:

SF009A_DutyCycThermProtn_Design

Synergy version matches change history

4.1.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 01.01.00

EA4 Software Naming Convention followed:

Version: 01.02.00

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.

Yes

Comments:

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:

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

Change Owner:

Matthew Leser

Review Date :

04/05/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Nakul Shah

Comments:

Integrator and or
SW lead:

Comments:

Integrator not needed for change

Unit test co-ordinator:

Comments:

Unit Test Co-ordinator not needed for change

Other Reviewer(s):

Mrudula

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

Sheet 4: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

DutyCycThermProtn_MDD.docx

MDD Revision:

6

Source File Name:

DutyCycThermProtn.c

Source File Revision:

10

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

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 SWC

N/A

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

Change Owner:

Matthew Leser

Review Date :

04/05/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Mrudula

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

Sheet 5: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

DutyCycThermProtn.c

Source File Revision:

10

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.04.00

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

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)

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)

Codemetrics count OK

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Change Owner:

Matthew Leser

Review Date :

04/05/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Mrudula

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

10.2 - DutyCycThermProtn_Integration Manual

Integration Manual

For

SF009A_DutyCycThermProtn

VERSION: 1.0

DATE: 02-Oct-2015

Prepared By:

Sarika Natu,

KPIT Technologies,

India

Revision History

Description	Author	Version	Date
Initial version	Sarika Natu	1.0	02-Oct-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 DutyCycThermProtn & High-Level Description 5

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

Sr. No.	Title	Version
1	MDD Guidelines	Software Process Release 04.02.00
2	Software Naming Conventions	Software Process Release 04.02.00
3	Design and Coding standards	Software Process Release 04.02.00
4	FDD – SF009A_DutyCycThermProtn_Design	See Synergy sub project 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
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
DutyCycThermProtnInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
DutyCycThermProtnPer1	None	RTE(100ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
DutyCycThermProtn_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>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

See DataDict.m

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

10.3 - DutyCycThermProtn_MDD

Module Design Document

For

DutyCycThermProtn

Apr 03, 2018

Prepared By:

Matthew Leser

Nexteer Automotive

Change History

Description	Author	Version	Date
Initial Version	Sarika Natu(KPIT Technologies)	1.0	02-Oct-2015
Updated to version 2.0.0 of FDD	Krishna Anne	2.0	07-Apr-2016
Fix for anomaly EA4# 7558	Krishna Anne	3.0	29-Sep-2016
Updated to FDD v3.0.0	Shruthi Raghavan	4.0	14-Dec-2016
Updated as per FDD v4.0.0	TATA	5.0	25-Oct-2017
Updated Local Function Input	Matthew Leser	6.0	03-Apr-2018

Table of Contents

2.1 Graphical representation of DutyCycThermProtn 6

2.2 Data Flow Diagram 7

2.2.1 Component level DFD 7

2.2.2 Function level DFD 7

3 Constant Data Dictionary 8

3.1 Program (fixed) Constants 8

3.1.1 Embedded Constants 8

4 Software Component Implementation 9

4.1 Sub-Module Functions 9

4.1.1 Init: DutyCycThermProtn_Init1 9

4.1.1.1 Design Rationale 9

4.1.1.2 Module Outputs 9

4.1.2 Per: DutyCycThermProtn_Per1 9

4.1.2.1 Design Rationale 9

4.1.2.2 Store Module Inputs to Local copies 9

4.1.2.3 (Processing of function)……… 9

4.1.2.4 Store Local copy of outputs into Module Outputs 9

4.2 Server Runables 9

4.3 Interrupt Functions 9

4.4 Module Internal (Local) Functions 9

4.4.1 Local Function #1 9

4.4.1.1 Design Rationale 9

4.4.1.2 Processing 10

4.4.2 Local Function #2 10

4.4.2.1 Design Rationale 10

4.4.2.2 Processing 10

4.4.3 Local Function #3 10

4.4.3.1 Design Rationale 10

4.4.3.2 Processing 10

4.4.4 Local Function #4 10

4.4.4.1 Design Rationale 11

4.4.4.2 Processing 11

4.4.5 Local Function #5 11

4.4.5.1 Design Rationale 11

4.4.5.2 Processing 11

4.4.6 Local Function #6 11

4.4.6.1 Design Rationale 11

4.4.7 Local Function #7 11

4.4.7.1 Design Rationale 12

4.4.8 Local Function #8 12

4.4.8.1 Design Rationale 12

4.4.8.2 Processing 12

4.5 GLOBAL Function/Macro Definitions 12

5 Known Limitations with Design 13

6 UNIT TEST CONSIDERATION 14

Appendix A Abbreviations and Acronyms 15

Appendix B Glossary 16

Appendix C References 17

DutyCycThermProtn & High-Level Description

The purpose of the Thermal Duty Cycle Protection is to limit and protect the system from excessive use, based on motor rotational velocity and system temperature. It also provides protection status information for use by other functions.

Design details of software module

Graphical representation of DutyCycThermProtn

Data Flow Diagram

See FDD

Component level DFD

See FDD

Function level DFD

See FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Refer .m file

Constant Name	Value
THERMLOADLIMSIZE_CNT_U08	8U
MULTFILTERSIZE_CNT_U08	6U
BITMASK2_CNT_U08	2U
BITMASK4_CNT_U08	4U
IDX5_CNT_U08	5U
IDX8_CNT_U08	8U

Software Component Implementation

Sub-Module Functions

Init: DutyCycThermProtn_Init1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: DutyCycThermProtn_Per1

Design Rationale

DutyCycThermProtn_Per1 function is divided into various functions to reduce the cyclomatic complexity.

The subsystems ‘Multiplier’ and ‘FilterPercMax’ are clubbed into ‘MultiFilterPercMax’ local function.

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

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	FiltSVReinit	Type	Min	Max
Arguments Passed	IgnTiOff_Cnt_T_u32	uint32	0	1720000
	VehTiVld_Cnt_T_Logl	Boolean	0	1
Return Value	None

Design Rationale

Name of local function matches with subsystem name from FDD

Processing

Local Function #2

Function Name	TemperatureSelection	Type	Min	Max
Arguments Passed	DiagcStsLimdTPrfmnc_Cnt_T_Logl	boolean	0	1
	EcuTFild_DegCgrd_T_f32	float32	-50	150
	MotFetT_DegCgrd_T_f32	float32	-50	200
	MotMagT_DegCgrd_T_f32	float32	-50	150
	MotWidgT_DegCgrd_T_f32	float32	-50	300
	*Mult12Temp_DegCgrd_T_ s15p0	Sint16	-50	200
	*Mult36Temp_DegCgrd_T_s15p0	Sint16	-50	300
Return Value	SlcTemp_DegCgrd_T_s15p0	sint16	-50	300

Design Rationale

Name of local function matches with subsystem name from FDD

Note: The outputs of the function are Mult12Temp_DegCgrd_T_s15p0, Mult36Temp_DegCgrd_T_s15p0 and SlcTemp_DegCgrd_T_f32.

Processing

None

Local Function #3

Function Name	TemperatureLimiting	Type	Min	Max
Arguments Passed	EcuTFild_DegCgrd_T_f32	float32	-50	150
	MotWidgT_DegCgrd_T_f32	float32	-50	300
Return Value	AbsTempLimitSlew_MotNwtMtr_T_f32	float32	0	8.79

Design Rationale

Name of local function matches with subsystem name from FDD

Processing

None

Local Function #4

Function Name	MultiFilterPercMax	Type	Min	Max
Arguments Passed	Mult12Temp_DegCgrd_T_s15p0	sint16	-50	200
	Mult36Temp_DegCgrd_T_s15p0	sint16	-50	300
	DutyCycThermProtnDi_Cnt_T_Logl	boolean	0	1
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
	MotCurrPeakEstimd_AmprSqd_T_f32	float32	0	62500
	MotCurrPeakEstimdFild_AmprSqd_T_f32	float32	0	62500
	*MaxOut_Uls_T_u16p0	uint16	0	200
Return Value	ThermLimSlowFilMax_Uls_T_f32	float32	0	200

Design Rationale

The subsystems ‘Multiplier’ and ‘FilterPercMax’ are clubbed into ‘MultiFilterPercMax’ local function.

Note: The outputs of the function are MaxOut_Uls_T_u16p0 and ThermLimSlowFilMax_Uls_T_f32.

Processing

None

Local Function #5

Function Name	ThermalLoadLimit	Type	Min	Max
Arguments Passed	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
	SlcTemp_DegCgrd_T_s15p0	sint16	-50	300
	MaxOut_Uls_T_u16p0	uint16	0	200
Return Value	ThermalLoadLmt_MotNwtMtr_T_f32	float32	0	8.8

Design Rationale

Name of local function matches with subsystem name from FDD

Processing

None

Local Function #6

Function Name	ThermalLimitStatus	Type	Min	Max
Arguments Passed	DutyCycThermProtnDi_Cnt_T_Logl	Boolean	0	1
	MaxOut_Uls_T_u16p0	uint16	0	200
	ThermMotTqLim_MotNwtMtr_T_f32	float32	0	8.8
	IvtrLoaMtgtnEna_Cnt_T_logl	boolean	FALSE	TRUE
	DualEcuFltMtgtnEna_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	ThermRednFac_Uls_T_f32	float32	0	1

Design Rationale

Name of local function matches with subsystem name from FDD. Initializing ThermRednFac_Uls_T_f32 to 0.0 helps to avoid writing another statement in the if-conditional (optimized compared to FDD)

Local Function #7

Function Name	TherrmalLimitScaling	Type	Min	Max
Arguments Passed	DualEcuFltMtgtnEna_Cnt_T_logl	Boolean	0	1
	IvtrLoaMtgtnEna_Cnt_T_logl	Boolean	0	1
	AbsTempLimitSlew_MotNwtMtr_T_f32	float32	0	8.79
	DutyCycThermProtnDi_Cnt_T_Logl	Boolean	0	1
	ThermalLoadLmt_MotNwtMtr_T_f32	float32	0	8.8
	* ThermLoadDptLim_MotNwtMtr_T_f32	Float32	0	8.8
	* ThermTempDptLim_MotNwtMtr_T_f32	Float32	0	8.8
Return Value	ThermMotTqLim_MotNwtMtr_T_f32	float32	0	8.8

Design Rationale

Name of local function matches with subsystem name from FDD

The if-action subsystem blocks for calculation of LoadDptLim and TempDptLim are clubbed together and optimized since the condition for the subsystem execution was same.

Local Function #8

Function Name	UseInpLowr	Type	Min	Max
Arguments Passed	*TableX_Cnt_T_s16	sint16	FULL	FULL
	*TableY_Cnt_T_u16	uint16	FULL	FULL
	Size_Cnt_T_u16	uint16	1	20
	Input_Cnt_T_s16	sint16	FULL	FULL
Return Value	TableY_Cnt_T_u16[Idx_Cnt_T_u08]	uint16	FULL	FULL

Design Rationale

None.

Processing

None

Local Function #9

Function Name	Decoder	Type	Min	Max
Arguments Passed	MotAndThermProtnLoaMod_Cnt_T_u08	Uint8	0U	255U
Return Value	IvtrLoaMtgtnEna_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

None.

Processing

Refer to the “Decoder” block of the Simulink model of the design.

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

In Init function CurrMeasLoaMtgtnEna and FetLoaMtgtnEna are terminated. In Periodic1 CurrMeasLoaMtgtnEna is terminated. These flags need not be computed at all.
MotAndThermProtnLoaMod input readable to init runnable also. It is need to update in Data Dictionary.

UNIT TEST CONSIDERATION

Function UseInpLowr to be tested only as called by the component; input and output ranges will not be reached.
Function UseInpLowr’s TableX must have strictly increasing elements.

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 02.00.00
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – SF009A_DutyCycThermProtn_Design	See Synergy sub project version

11 - Component Implementation

Component Implementation

Component Documentation

11.1 - ElecPwrCns_IntegrationManual

Integration Manual

For

Electric Power Consumption

VERSION: 1.0

DATE: 10-May-2016

Prepared By:

Vishnu Mohan (Tata Elxsi),

Trivandrum, INDIA.

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Vishnu Mohan	1.0	05/10/2016

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 : SF109A_ElecPwrCns_Design	See Synergy sub project version
2	Software Naming Conventions	1.0
3	Software Design and Coding Standards	2.0

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

Runnable	Scheduling Requirements	Trigger
ElecPwrCnsPer1	None	RTE(10 ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

Module Design Document

For

ElecPwrCns

SepMay 2510, 20167

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

TATA Trivandrum, INDIA

Change History

Description	Author	Version	Date
Initial Version	Vishnu Mohan	1.0	10-May-2016
Updated to FDD v2.0.0	TATA	2.0	25-Sep-2017

Table of Contents

2 ElecPwrCns & High-Level Description 5

3.1 Graphical representation of ElecPwrCns 6

5.1.1 Per: ElecPwrCnsPer1 8

5.1.1.2 Store Module Inputs to Local copies 8

5.1.1.3 (Processing of function)……… 8

5.1.1.4 Store Local copy of outputs into Module Outputs 8

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
PolySpace

Introduction

Purpose

MDD for Electrical Electric Power Consumption

ElecPwrCns & High-Level Description

Please refer FDD

Design details of software module

Graphical representation of ElecPwrCns

Data Flow Diagram

Please refer FDD

Component level DFD

Please refer FDD

Function level DFD

Please refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Please refer the .m file
BITMASK1_CNT_U08	uint8	CNT	1U
BITMASK2_CNT_U08	uint8	CNT	2U
BITMASK4_CNT_U08	uint8	CNT	4U

Software Component Implementation

Sub-Module Functions

Per: ElecPwrCnsPer1

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Please refer FDD

Store Local copy of outputs into Module Outputs

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

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: SF109A_ElecPwrCns_Design	See Synergy sub project version

11.3 - ElecPwrCns_Review

Overview

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. SF109A_ElecPwrCns_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. SF109A_ElecPwrCns_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. Ramachandran(Tata Elxsi)

Work CR ID:

EA4#13249

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:

Krishna Anna

Review Date :

10/09/17

Lead Peer Reviewer:

Krishna Anna

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)

NA for the changes

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

NA for the changes

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:

NA for the changes

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

NA for the changes

Component is correct component type

Yes

Comments:

General Notes / Comments:

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:

Ramachandran(Tata Elxsi)

Review Date :

10/09/17

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:

ElecPwrCns.c

Source File Revision:

2

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:

ElecPwrCns_MDD

Revision:

2.0

FDD/SCIR/DSR/FDR/CM Name:

SF109A_ElecPwrCns_Design

Revision:

2.0.0

Quality Check Items:

Rationale is required for all answers of No

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]

NA for the changes

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:

Ramachandran(Tata Elxsi)

Review Date :

10/09/17

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:

ElecPwrCns_MDD

MDD Revision:

2.0

Source File Name:

ElecPwrCns.c

Source File Revision:

2

Source File Name:

NA

Source File Revision:

NA

Source File Name:

NA

Source File Revision:

NA

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:

Ramachandran(Tata Elxsi)

Review Date :

10/09/17

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:

ElecPwrCns.c

Source File Revision:

2

Source File Name:

NA

Source File Revision:

NA

Source File Name:

NA

Source File Revision:

NA

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 1.3.0

QAC version:

Windows User: eg 8.1.1-R NA

QAC sub project version:

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

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:

Ramachandran(Tata Elxsi)

Review Date :

10/09/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

12 - Component Implementation

Component Implementation

Component Documentation

12.1 - EotLrng_IntegrationManual

Integration Manual

For

End of Travel Learning (SF011A)

VERSION: 4.0

DATE: 14-March-2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Matthew Leser,

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Akhil Krishna N D	1.0	09/24/2015
2	Updated for v2.0.0 of FDD	Nick Saxton	2.0	05/19/2016
3	Updated to design version 3.1.0	TATA	3.0	05-Dec-16
4	Updated to design version 3.2.0	ML	4.0	14-March-17

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1.1 RTE NvM Blocks 10

1 End of Travel Learning & High-Level Description 5

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 : SF011A_EotLrng_Design	See Synergy sub project version
2	Software Naming Conventions	Process 4.02.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
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
EotLrngInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
EotLrngPer1	None	RTE (10 ms)
SerlComRstEot_Oper	None	On event
RtnMaxHwAgCwAndCcw	None	On event
RstMaxHwAgCwAndCcw	None	On event
GetHwAgOverTrvlCnt	None	On event
RstHwAgOverTrvlCnt	None	On event
SetHwAgOverTrvlCnt	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

NOTE: In Autosar, Store at Shutdown and Restore at Startup were turned off for NVM Block Needs for NvmMaxHwAgCwAndCcw and NvmEotNvmData. This was done to remove warnings given during check. These will need to be turned back on during integration.

RTE NvM Blocks

Block Name

EotNvmData

MaxHwAgCwAndCcw

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None.

Appendix

None

12.2 - EotLrng_MDD

Module Design Document

For

EotLrng (SF011A)

March 7, 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	Akhil Krishna N D	1.0	30-Sep-2015
Updated for v2.0.0 of FDD	Nick Saxton	2.0	19-May-2016
Updated for v2.1.0 of FDD	Nick Saxton	3.0	16-Jun-2016
Updated for v3.1.0 of FDD	TATA	4.0	05-Dec-2016
Updated for v3.2.0 of FDD	Matthew Leser	5.0	07-March-2017

Table of Contents

2.1 Graphical representation of End of Travel Learning 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

4 Software Component Implementation 8

4.1 Sub-Module Functions 8

4.1.1 Init: EotLrngInit1 8

4.1.1.1 Design Rationale 8

4.1.1.2 Module Outputs 8

4.1.2 Per: EotLrngPer1 8

4.1.2.1 Design Rationale 8

4.1.2.2 Store Module Inputs to Local copies 8

4.1.2.3 (Processing of function)……… 8

4.1.2.4 Store Local copy of outputs into Module Outputs 8

4.2 Server Runnable 8

4.2.1 SerlComRstEot 8

4.2.1.1 Design Rationale 8

4.2.1.2 (Processing of function)……… 8

4.3 Interrupt Functions 8

4.3.1 RtnMaxHwAgCwAndCcw 9

4.3.1.1 Design Rationale 9

4.3.1.2 (Processing of function)……… 9

4.4 Interrupt Functions 9

4.4.1 RstMaxHwAgCwAndCcw 9

4.4.1.1 Design Rationale 9

4.4.1.2 (Processing of function)……… 9

4.5 Interrupt Functions 9

4.5.1.3 (Processing of function)……… 9

4.6 Interrupt Functions 9

4.6.1.3 (Processing of function)……… 9

4.7 Interrupt Functions 9

4.7.1.3 (Processing of function)……… 10

4.8 Interrupt Functions 10

4.9 Module Internal (Local) Functions 10

4.9.1 Local Function #1 10

4.9.1.1 Design Rationale 10

4.9.1.2 Processing 10

4.9.2 Local Function #2 10

4.9.2.1 Design Rationale 11

4.9.2.2 Processing 11

4.10 GLOBAL Function/Macro Definitions 11

4.10.1 GLOBAL Function #1 11

4.10.1.1 Design Rationale 11

4.10.1.2 Processing 11

5 Known Limitations with Design 12

6 UNIT TEST CONSIDERATION 13

Summary Sheet
Synergy Project
Source Code
PolySpace

End of Travel Learning & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation of End of Travel Learning

Data Flow Diagram

Please refer FDD.

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Please refer .m file

Software Component Implementation

Sub-Module Functions

Init: EotLrngInit1

Design Rationale

None

Module Outputs

Please refer FDD.

Per: EotLrngPer1

Design Rationale

None

Store Module Inputs to Local copies

Please refer FDD.

(Processing of function)………

Please refer FDD and design rationale noted above.

Store Local copy of outputs into Module Outputs

Please refer FDD.

Server Runnable

SerlComRstEot

Design Rationale

None

(Processing of function)………

Please refer SerlComRstEot block in FDD

Interrupt Functions

None

RtnMaxHwAgCwAndCcw

Design Rationale

None

(Processing of function)………

Please refer RtnMaxHwAgCwAndCcw block in FDD

Interrupt Functions

None

RstMaxHwAgCwAndCcw

Design Rationale

None

(Processing of function)………

Please refer RstMaxHwAgCwAndCcw block in FDD

Interrupt Functions

None

GetHwAgOverTrvlCnt

Design Rationale

None

(Processing of function)………

Please refer GetHwAgOverTrvlCnt block in FDD

Interrupt Functions

None

RstHwAgOverTrvlCnt

Design Rationale

None

(Processing of function)………

Please refer RstHwAgOverTrvlCnt block in FDD

Interrupt Functions

None

SetHwAgOverTrvlCnt

Design Rationale

None

(Processing of function)………

Please refer SetHwAgOverTrvlCnt block in FDD

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	LrngEotCmplSts	Type	Min	Max
Arguments Passed	HwAgAuthy_Uls_T_f32	float32	0	1
	HwTq_HwNwtMtr_T_f32	float32	-10	10
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
Return Value	None	-	-	-

Design Rationale

To reduce the static path count

Processing

Please refer to the “LrngEotCmplSts” block of the Simulink model of the design.

Local Function #2

Function Name	ChkEotSigForNtc	Type	Min	Max
Arguments Passed	HwAgEotSig0Avl_Cnt_T_lgc	boolean	FALSE	TRUE
	HwAgEotSig1Avl_Cnt_T_lgc	boolean	FALSE	TRUE
	HwAgEotSig0Cw_HwDeg_T_f32	float32	0	900
	HwAgEotSig0Ccw_HwDeg_T_f32	float32	-900	0
	HwAgEotSig1Cw_HwDeg_T_f32	float32	0	900
	HwAgEotSig1Ccw_HwDeg_T_f32	float32	-900	0
Return Value	None	-	-	-

Design Rationale

To reduce the static path count

Processing

Please refer to the “ChkEotSigForNtc” block of the Simulink model of the design.

Local Function #3

Function Name	OverTrvlDiagc	Type	Min	Max
Arguments Passed	HwAg_HwDeg_T_f32	float32	-1440	1440
Return Value	None	-	-	-

Design Rationale

To reduce the static path count

Processing

Please refer to the “OverTrvlDiagc” block of the Simulink model of the design.

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

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 : SF011A_EotLrng_Design	See Synergy sub project version

12.3 - EotLrng_Review

Overview

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. SF011A_EotLrng_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. SF011A_EotLrng_Impl_3.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#12511

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:

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

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 :

07/05/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi R

Krishna Anne

Brendon Binder

Shawn Penning

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

EotLrng.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:

EotLrng_MDD.doc

Revision:

5

FDD/SCIR/DSR/FDR/CM Name:

SF011A_EotLrng_Design

Revision:

3.2.0

Quality Check Items:

Rationale is required for all answers of No

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
PolySpace

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

No need of Requirement tags

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

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:

Matthew Leser

Review Date :

07/05/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi R

Krishna Anne

Brendon Binder

Shawn Penning

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

EotLrng.c

Source File Revision:

7

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

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 :

07/05/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi R

Krishna Anne

Brendon Binder

Shawn Penning

13 - Component Implementation

Component Implementation

Component Documentation

13.1 - EotProtn_DesignReview

Overview

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. SF018A_EotProtn_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. SF018A_EotProtn_Impl_1.8.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#13598

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 :

07/25/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

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 :

07/25/17

Component Type :

Application

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

EotProtn.c

Source File Revision:

9

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:

EotProtn_MDD

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

SF018A_EotProtn_Design

Revision:

1.9.0

Quality Check Items:

Rationale is required for all answers of No

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

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:

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 :

07/25/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

EotProtn_MDD.doc

MDD Revision:

3

Source File Name:

EotProtn.c

Source File Revision:

9

Source File Name:

NA

Source File Revision:

Source File Name:

NA

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

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:

Matthew Leser

Review Date :

08/16/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Avinash James

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

EotProtn.c

Source File Revision:

9

Source File Name:

NA

Source File Revision:

NA

Source File Name:

NA

Source File Revision:

NA

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b R2013B

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

Removed deviation comments that no longer apply

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:

12.4 warning exists because the way Polyspace treats the right hand side of OR statement which contains functions that Polyspace can't calculate outcome of.

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 :

08/16/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Avinash

13.2 - EotProtn_Integration Manual

Integration Manual

For

SF018A_EotProtn

VERSION: 1.0

DATE: 01-Oct-2015

Prepared By:

Sarika Natu,

KPIT Technologies,

India

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

Revision History

Description	Author	Version	Date
Initial version	Sarika Natu	1.0	01-Oct-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 EotProtn & High-Level Description 5

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	Software Process Release 04.02.00
2	Software Naming Conventions	Software Process Release 04.02.00
3	Design and Coding standards	Software Process Release 04.02.00
4	FDD – SF018A_EotProtn_Design	See Synergy sub project 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
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
EotProtnInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
EotProtnPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
EotProtn_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>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

13.3 - EotProtn_MDD

Module Design Document

For

EotProtn

Aug 16, 2017

Prepared By:

Matthew Leser

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Change History

SNo.	Description	Author	Version	Date
1	Initial Version	Sarika Natu(KPIT Technologies)	1.0	01-Oct-2015
2	Implemented SF018A design version 1.5.0	SB	2.0	01-Jul-2016
3	Updated Graph, Function Inputs, and Unit Test Considerations	Matthew Leser	3.0	16-Aug-2017

Table of Contents

2.1 Graphical representation of EotProtn 6

2.2 Data Flow Diagram 7

2.2.1 Component level DFD 7

2.2.2 Function level DFD 7

3 Constant Data Dictionary 8

3.1 Program (fixed) Constants 8

3.1.1 Embedded Constants 8

4 Software Component Implementation 9

4.1 Sub-Module Functions 9

4.1.1 Init: EotProtn_Init1 9

4.1.1.1 Design Rationale 9

4.1.1.2 Module Outputs 9

4.1.2 Per: EotProtn_Per1 9

4.1.2.1 Design Rationale 9

4.1.2.2 Store Module Inputs to Local copies 9

4.1.2.3 (Processing of function)……… 9

4.1.2.4 Store Local copy of outputs into Module Outputs 9

4.2 Server Runables 9

4.3 Interrupt Functions 9

4.4 Module Internal (Local) Functions 9

4.4.1 Local Function #1 9

4.4.1.1 Design Rationale 10

4.4.1.2 Processing 10

4.4.2 Local Function #2 10

4.4.2.1 Design Rationale 10

4.4.2.2 Processing 10

4.4.3 Local Function #3 10

4.4.3.1 Design Rationale 10

4.4.3.2 Processing 10

4.4.4 Local Function #4 11

4.4.4.1 Design Rationale 11

4.4.4.2 Processing 11

4.4.5 Local Function #5 11

4.4.5.1 Design Rationale 11

4.4.5.2 Processing 11

4.4.6 Local Function #6 11

4.4.6.1 Design Rationale 11

4.4.6.2 Processing 11

4.4.7 Local Function #7 11

4.4.7.1 Design Rationale 12

4.4.7.2 Processing 12

4.4.8 Local Function #8 12

4.4.8.1 Design Rationale 12

4.4.8.2 Processing 12

4.4.9 Local Function #9 12

4.4.9.1 Design Rationale 13

4.4.9.2 Processing 13

4.5 GLOBAL Function/Macro Definitions 13

5 Known Limitations with Design 14

6 UNIT TEST CONSIDERATION 15

Appendix A Abbreviations and Acronyms 16

Appendix B Glossary 17

Appendix C References 18

EotProtn & High-Level Description

The End of Travel Protection function specifies performance attributes as the steering system approaches the mechanical end of travel of the steering gear.

Design details of software module

Graphical representation of EotProtn

Data Flow Diagram

See FDD

Component level DFD

See FDD

Function level DFD

See FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant	Value
DAMPGPTSIZE_CNT_U08	2
DAMPGVEHSPDSIZE_CNT_U08	4
GAINVEHSPDSIZE_CNT_U08	5

Software Component Implementation

Sub-Module Functions

Init: EotProtn_Init1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: EotProtn_Per1

Design Rationale

EotProtn_Per1 function is divided into various functions to reduce the cyclomatic complexity.

The limiting of ‘EotAssiSca’ output is performed in SoftEndStop subsystem in FDD. But in code it is limiting calculations are done where the output is calculated i.e. FildEotGain function.

The model is incorrectly handling a Case Statement by not having a default case. A solution was discussed with designers and has been implemented where the default case is Case 2 and Case 3.

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

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	EotVelImpct	Type	Min	Max
Arguments Passed	HwAgEotCw_HwDeg_T_f32	float32	360	900
	HwAgEotCcw_HwDeg_T_f32	float32	-900	-360
	HwAg_HwDeg_T_f32	float32	-1440	1440
	VehSpd_Kph_T_f32	float32	0	511
	HwAgAuthy_Uls_T_f32	float32	0	1
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
Return Value	EotMotTqLim_MotNwtMtr_T_f32	float32	0	8.8

Design Rationale

None

Note: Outputs of “EotVelImpct” function is - EotMotTqLim_MotNwtMtr_T_f32.

Processing

Refer to the “EotVelImpct” subsystem of the Simulink model of the design

Local Function #2

Function Name	LimPosnDetd	Type	Min	Max
Arguments Passed	RackTrvlLimrRngEna_Cnt_T_logl	boolean	False	True
	HwAgEotCw_HwDeg_T_f32	float32	360	900
	HwAgEotCcw_HwDeg_T_f32	float32	-900	-360
	HwAg_HwDeg_T_f32	float32	-1440	1440
Return Value	LimPosn_HwDeg_T_f32	float32	-1440	1440

Design Rationale

None

Note: Outputs of “LimPosnDetd” function is - LimPosn_HwDeg_T_f32.

Processing

Refer to the “LimPosnDetd” subsystem of the Simulink model of the design

Local Function #3

Function Name	CalcEntrGain	Type	Min	Max
Arguments Passed	HwAg_HwDeg_T_f32	float32	-1440	1440
	VehSpd_Kph_T_f32	float32	0	511
	LimPosn_HwDeg_T_f32	float32	-1440	1440
	HwAgAuthy_Uls_T_f32	float32	0	1
Return Value	EntrGain_Uls_T_f32	float32	0	1

Design Rationale

None

Note: Outputs of “CalcEntrGain” function is - EntrGain_Uls_T_f32.

Processing

Refer to the “CalcEntrGain” subsystem of the Simulink model of the design

Local Function #4

Function Name	CalcExitGain	Type	Min	Max
Arguments Passed	HwTq_HwNwtMtr_T_f32	float32	-10	10
Return Value	ExitGain_Uls_T_f32	float32	0	1

Design Rationale

Calculation of Filtered Handwheel torque is done after ‘CalcExitGain’ function is executed.

Note: Outputs of “CalcExitGain” function is - FildHwTq_HwNwtMtr_T_f32

Processing

Refer to the “CalcExitGain” subsystem of the Simulink model of the design

Local Function #5

Function Name	CalcEotGain	Type	Min	Max
Arguments Passed	EntrGain_Uls_T_f32	float32	0	1
	ExitGain_Uls_T_f32	float32	0	1
Return Value	EotGain_Uls_T_f32	float32	0	1

Design Rationale

None

Note: Outputs of “CalcEotGain” function is - EotGain_Uls_T_f32

Processing

Refer to the “CalcEotGain” subsystem of the Simulink model of the design

Local Function #6

Function Name	FildEotGain	Type	Min	Max
Arguments Passed	EotGain_Uls_T_f32	float32	0	1
Return Value	EotAssiSca_Uls_T_f32	float32	0	1

Design Rationale

Limit of EotAssiSca is moved to local function FildEotGain.

Note: Outputs of “FildEotGain” function is - EotAssiSca_Uls_T_f32

Processing

Refer to the “FildEotGain” subsystem of the Simulink model of the design

Local Function #7

Function Name	CalcEotDampg	Type	Min	Max
Arguments Passed	HwAg_HwDeg_T_f32	float32	-1440	1440
	VehSpd_Kph_T_f32	float32	0	511
	HwAgEotCw_HwDeg_T_f32	float32	360	900
	HwAgEotCcw_HwDeg_T_f32	float32	-900	-360
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
Return Value	EotDampgCmd_MotNwtMtr_T_f32	float32	-8.8	8.8

Design Rationale

None

Note: Outputs of “CalcEotDampg” function is - EotDampgCmd_MotNwtMtr_T_f32

Processing

Refer to the “CalcEotDampg” calculation of the Simulink model of the design

Local Function #8

Function Name	EotActvCmdCalc	Type	Min	Max
Arguments Passed	RackTrvlLimrDi_Cnt_T_logl	boolean	False	True
	HwAgAuthy_Uls_T_f32	float32	0	1
	VehSpd_Kph_T_f32	float32	0	511
	HwAg_HwDeg_T_f32	float32	-1440	1440
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
	LimPosn_HwDeg_T_f32	float32	-1440	1440
Return Value	EotActvCmd_MotNwtMtr_T_f32	float32	-8.8	8.8

Design Rationale

None

Note: Outputs of “EotActvCmdCalc” function is - EotActvCmd_MotNwtMtr_T_f32

Processing

Refer to the “EotActvCmdCalc” calculation of the Simulink model of the design

Local Function #9

Function Name	SoftEndStopStCtrl	Type	Min	Max
Arguments Passed	VehSpd_Kph_T_f32	float32	0	511
	HwAgAuthy_Uls_T_f32	float32	0	1
	EotProtnDi_Cnt_T_Logl	boolean	0	1
	EotDetd_Cnt_T_Logl	boolean	0	1
	HwAg_HwDeg_T_f32	float32	-1440	1440
	FildHwTq_HwNwtMtr_T_f32	float32	-3.4E+38	3.4E+38
	SysMotTqCmdSca_Uls_T_f32	float32	0	1
	LimPosn_HwDeg_T_f32	float32	-1440	1440
Return Value	None	float32	-8.8	8.8

Design Rationale

None

Processing

Refer to the “SoftEndStopStCtrl” calculation of the Simulink model of the design

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

Source Model Mismatch will occur in PIL Testing. This is because the model is incorrectly handling a Case Statement by not having a default case. A solution was discussed with designers and has been implemented where the default case is Case 2 and Case 3. The design will be updated later through ICR EA4#14690.

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)	Process release 04.02.01
2	MDD Guideline	Process release 04.02.01
3	Software Naming Conventions.doc	2.0
4	Software Design and Coding Standards.doc	2.1
5	SF018A_EotProtn_Design	See Synergy subproject version

14 - Component Implementation

Component Implementation

Component Documentation

14.1 - EotProtnFwl_Integration Manual

Integration Manual

For

SF027A_EotProtnFwl

VERSION: 1.0

DATE: 01-Feb-2016

Prepared By:

Sarika Natu,

KPIT Technologies,

India

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

Revision History

Description	Author	Version	Date
Initial version	Sarika Natu	1.0	01-Feb-2016

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 EotProtnFwl & High-Level Description 5

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 Guideline	EA4 01.00.00
2	Software Naming Conventions.doc	2.0
3	Software Design and Coding Standards.doc	2.1
4	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
5	SF027_EotProtnFwl_Design	Refer 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
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
EotProtnFwlInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
EotProtnFwlPer1	None	RTE(2ms)

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
EotProtnFwl_START_SEC_CODE
EotProtnFwl_STOP_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>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

14.2 - EotProtnFwl_MDD

Module Design Document

For

EotProtnFwl

Feb 01, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Sarika Natu,

KPIT Technologies,

India

Change History

Description	Author	Version	Date
Initial Version	Sarika Natu(KPIT Technologies)	1.0	01-Feb-2016

Table of Contents

2.1 Graphical representation of EotProtnFwl 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

4 Software Component Implementation 8

4.1 Sub-Module Functions 8

4.1.1 Init: EotProtnFwl_Init1 8

4.1.1.1 Design Rationale 8

4.1.1.2 Module Outputs 8

4.1.2 Per: EotProtnFwl_Per1 8

4.1.2.1 Design Rationale 8

4.1.2.2 Store Module Inputs to Local copies 8

4.1.2.3 (Processing of function)……… 8

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

4.4.1 Local Function #1 8

4.4.1.1 Design Rationale 9

4.4.1.2 Processing 9

4.4.2 Local Function #2 9

4.4.2.1 Design Rationale 9

4.4.2.2 Processing 9

4.5 GLOBAL Function/Macro Definitions 9

5 Known Limitations with Design 10

6 UNIT TEST CONSIDERATION 11

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

EotProtnFwl & High-Level Description

EOT Protection Firewall function is safety function which imposes a firewall limit to the Assist_EOTDamping and EOTActvCmd motor commands generated by SF-018A.

Design details of software module

Graphical representation of EotProtnFwl

$C:\Users\fzd2x9\Desktop\SF027A_EotProtnFwl_Impl.png$

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

Refer FDD

Software Component Implementation

Sub-Module Functions

Init: EotProtnFwl_Init1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: EotProtnFwl_Per1

Design Rationale

EotProtnFwl_Per1 function is divided into various functions to reduce the cyclomatic complexity.

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

Function Name	DetEOTDamping	Type	Min	Max
Arguments Passed	EotDampgCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	EotProtnDi_Cnt_T_Logl	boolean	0	1
	HwAg_HwDeg_T_f32	float32	-1440.0	1440.0
	MotVelCrf_MotRadPerSec_T_f32	float32	- 1118.0	1118.0
	EotProtnFwlPinionAgConfSts_Cnt_T_Logl	boolean	0	1
	VehSpd_Kph_T_u9p7	uint16	0	511
	MfgEnaSt_Cnt_T_Enum	Enum	0	1
	* EotDampgFwlReached_Cnt_T_Logl	boolean	0	1
Return by Value	EotDampgCmdLimd_MotNwtMtr_T_f32	float32	-8.8	8.8

Design Rationale

This function updates EotDampgFwlReached_Cnt_T_Logl

Processing

Refer Active/Inactive region for EOTDamping Command implementation in model

Local Function #2

Function Name	DetEOTActive	Type	Min	Max
Arguments Passed	EotActvCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	EotProtnDi_Cnt_T_Logl	boolean	0	1
	HwAg_HwDeg_T_f32	float32	-1440.0	1440.0
	EotProtnFwlPinionAgConfSts_Cnt_T_Logl	boolean	0	1
	VehSpd_Kph_T_u9p7	uint16	0	511
	MfgEnaSt_Cnt_T_Enum	Enum	0	1
	* EotActvCmdFwlReached_Cnt_T_Logl	boolean	0	1
Return Value	EotActvCmdLimd_MotNwtMtr_T_f32	float32	-8.8	8.8

Design Rationale

This function updates EotActvCmdFwlReached_Cnt_T_Logl

Processing

Refer Active/Inactive region for EOT Active Command implementation in model

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	SF027_EotProtnFwl_Desgin	Please refer synergy subproject version

14.3 - EotProtnFwl_PeerReviewChecklist

Overview

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. SF027A_EotProtnFwl_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. Matthew Leser

Work CR ID:

EA4#9744

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 :

03/01/17

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash James

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

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 :

03/01/17

Component Type :

Application

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

EotProtnFwl.c

Source File Revision:

2

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:

EotProtnFwl_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF027A_EotProtnFwl_Design

Revision:

1.3.0

Quality Check Items:

Rationale is required for all answers of No

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:

All other includes are actually needed. (System includes

N/A

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

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:

Matthew Leser

Review Date :

03/01/17

Lead Peer Reviewer:

JK

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:

EotProtnFwl.c

Source File Revision:

3

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

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 TL_100A_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/01/17

Lead Peer Reviewer:

JK

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash James

15 - Component Implementation

Component Implementation

Component Documentation

15.1 - HiLoadStallLimr_IntegrationManual

Integration Manual

For

HiLoadStallLimr

VERSION: 1.0

DATE: 19-AUG-2015

Prepared By:

Krishna Kanth 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	Krishna Kanth Anne	1.0	19-Aug-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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

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

Runnable	Scheduling Requirements	Trigger
HiLoadStallLimrPer1	None	RTE(2ms)

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

Module Design Document

For

HiLoadStallLimr

March 22, 2018

Prepared By:

Jayakrishnan T,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Krishna Kanth Anne	EA4 01.00.01	19-Aug-2015
Updated to Design Ver 2.0.0	Matthew Leser	2.0	28-Feb-2017
Updated Diagram	Matthew Leser	3.0	20-Oct-2017
Updated Local constant values	Jayakrishnan T	4.0	22-Mar-2018

Table of Contents

2 HiLoadStallLimr & High-Level Description 6

3.1 Graphical representation of HiLoadStallLimr 7

5.1.1 Init: HiLoadStallLimrInit1 9

5.1.2 Per: HiLoadStallLimrPer1 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runables 9

5.4 Module Internal (Local) Functions 9

5.4.1 Local Function #1 9

5.5 GLOBAL Function/Macro Definitions 10

5.5.1 GLOBAL Function #1 10

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace
help
Version History

Introduction

Purpose

MDD for HiLoadStallLimr

HiLoadStallLimr & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation of HiLoadStallLimr

Data Flow Diagram

Please refer FDD.

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Please refer .m file
IVTRLOABITMASK_CNT_U08	1	CNT	2U
FETLOABITMASK_CNT_U08	1	CNT	4U

Software Component Implementation

Sub-Module Functions

None

Init: HiLoadStallLimrInit1

Design Rationale

Module Outputs

None

Per: HiLoadStallLimrPer1

Design Rationale

None

Store Module Inputs to Local copies

Please refer FDD

(Processing of function)………

Please refer FDD

Store Local copy of outputs into Module Outputs

Please refer FDD

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

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

GLOBAL Function/Macro Definitions

GLOBAL Function #1

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

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.0
5	FDD : SF017A_HiLoadStallLimr_Design	See Synergy sub project version

15.3 - HiLoadStallLimr_Review

Overview

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

HiLoadStallLimr

Revision / Baseline:

SF017A_HiLoadStallLimr_Impl_3.1.0

Change Owner:

Jayakrishnan T

Work CR ID:

EA4#21877

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

Yes

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

All required reviewers participated

No

Comments:

Siva did an offline review of the changes as he was busy with other meetings and I had to get the component

reviewed before Noon

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

0.5

0

Component developer reviewers:

0

0.5

0

1.5

Other reviewers:

0

Total hours

0.5

1

0

1.5

Content reviewed

Lines of code:

6

Elements of .arxml content:

0

Pages of documentation:

3

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:

Change Owner:

Jayakrishnan T

Review Date :

03/22/18

Lead Peer Reviewer:

Matt Lesser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

HiLoadStallLimr.c

Source File Revision:

4

Header File Name:

Header File Revision:

MDD Name:

HiLoadStallLimr_MDD.docx

4

SWC Design Name:

SF017A_HiLoadStallLimr_Design

Synergy version matches change history

3.1.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Yes

Version:

EA4 Software Naming Convention followed:

Yes

Version:

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:

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

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

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

Yes

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:

Change Owner:

Jayakrishnan T

Review Date :

03/22/18

Lead Peer Reviewer:

Matt Lesser

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Siva

Comments:

Integrator and or
SW lead:

Akilan

Comments:

Unit test co-ordinator:

Vivek

Comments:

Other Reviewer(s):

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

Sheet 4: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

HiLoadStallLimr_MDD.docx

MDD Revision:

4

Source File Name:

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

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 SWC

N/A

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

Change Owner:

Jayakrishnan T

Review Date :

03/22/18

Lead Peer Reviewer:

Matt Lesser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 5: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

HiLoadStallLimr.c

Source File Revision:

4

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.04.00

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

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)

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)

Codemetrics count OK

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Change Owner:

Jayakrishnan T

Review Date :

03/22/18

Lead Peer Reviewer:

Matt Lesser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

16 - Component Implementation

Component Implementation

Component Documentation

16.1 - HwAgSnsrls_IntegrationManual

Integration Manual

For

HwAgSnsrls

VERSION:2.0

DATE: 27-March-2017

Prepared By:

Matthew Leser

Software Engineering

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	TATA	1.0	06/30/2016
2	Updated for NVM Block changes in AutoSAR	ML	2.0	03/27/2017

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1.1 RTE NvM Blocks 10

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

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

Runnable	Scheduling Requirements	Trigger
HwAgSnsrlsPer1	None	RTE (2ms)
FSnsrlsHwCentr_Oper	None	On event
RstSnsrlsHwCentr_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

RTE NvM Blocks

Block Name

StordLstPrm (NOTE: Restore at Startup and Store At Shutdown were unchecked for check in Davinci Devloper. These will need to be turned back on)

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

16.2 - HwAgSnsrls_MDD

Module Design Document

For

HwAgSnsrls

VERSION: 4.0

DATE: 17-Nov-2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

TATA ELXSI

CHENNAI, INDIA

Change History

Description	Author	Version	Date
Initial Version	TATA	1.0	29-Jun-2016
Implemented design 1.2.0, 1.3.0 and fixed anomaly 6881	Hari Mattupalli	2.0	22-Sep-2016
Implemented design 1.4.0 and fixed anomaly 7844	Hari Mattupalli	3.0	21-Oct-2016
Updated per design rev. 1.6.0	TATA	4.0	17-Nov-2016

Table of Contents

2 HwAgSnsrls & High-Level Description 6

3.1 Graphical representation of HwAgSnsrls 7

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

5.1.1 Init: HwAgSnsrlsInit1 10

5.1.1.1 Design Rationale 10

5.1.1.2 Module Outputs 10

5.1.2 Per: HwAgSnsrlsPer1 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.2 Server Runnables 10

5.2.1 FSnsrlsHwCentr 10

5.2.1.1 Design Rationale 10

5.2.1.2 (Processing of function)……… 10

5.2.2 RstSnsrlsHwCentr 11

5.2.2.1 Design Rationale 11

5.2.2.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.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 13

5.4.4 Local Function #4 13

5.4.4.1 Design Rationale 13

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

Introduction

Purpose

MDD for Handwheel Angle Sensorless.

HwAgSnsrls & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation of HwAgSnsrls

$E:\Doc\SF042A.JPG$

Data Flow Diagram

Component level DFD

Please refer FDD.

Function level DFD

Please refer FDD.

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Units	Value
Please refer Data Dictionary .m file	NA	NA

Software Component Implementation

Sub-Module Functions

Init: HwAgSnsrlsInit1

Design Rationale

None

Module Outputs

None

Per: HwAgSnsrlsPer1

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Please refer FDD

Store Local copy of outputs into Module Outputs

Please refer FDD

Server Runnables

FSnsrlsHwCentr

Design Rationale

None

(Processing of function)………

Please see FSnsrlsHwCentr block in FDD

RstSnsrlsHwCentr

Design Rationale

None

(Processing of function)………

Please see RstSnsrlsHwCentr block in FDD

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	WhlSpdAutocentr	Type	Min	Max
Arguments Passed	WhlFrqVld_Cnt_T_lgc	boolean	FALSE	TRUE
	WhlLeFrq_Hz_T_f32	float32	0.01F	60.0F
	WhlRiFrq_Hz_T_f32	float32	0.01F	60.0F
	VehSpd_Kph_T_f32	float32	0.0F	511.0F
	RelHwAg_HwDeg_T_f32	float32	-1440.0F	1440.0F
	*WhlSpdHwConf_Uls_T_f32	float32	0.0F	1.0F
Return Value	None

Design Rationale

None.

Processing

Refer to the “WhlSpdAutocentr” block of the Simulink model of the design.

Local Function #2

Function Name	VehDynAutoCentr	Type	Min	Max
Arguments Passed	MotTqCmdCrf_MotNwtMtr_T_f32	float32	-8.8	8.8
	HwTq_HwNwtMtr_T_f32	float32	-10.0F	10.0F
	VehYawRate_VehDegPerSec_T_f32	float32	-120.0F	120.0F
	VehSpd_Kph_T_f32	float32	0.0F	511.0F
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350.0F	1350.0F
	VehSpdVld_Cnt_T_logl	Boolean	FALSE	TRUE
	RelHwAg_HwDeg_T_f32	float32	-1440.0F	1440.0F
	*VehDynHwConf_Uls_T_f32	float32	0.0F	1.0F
Return Value	None

Design Rationale

None.

Processing

Refer to the “VehDynAutoCentr” block of the Simulink model of the design.

Local Function #3

Function Name	PinionTqCalcandLpFilOneEna	Type	Min	Max
Arguments Passed	MotTqCmdCrf_MotNwtMtr_T_f32	float32	-8.8	8.8
	HwTq_HwNwtMtr_T_f32	float32	-10.0F	10.0F
	VehYawRate_VehDegPerSec_T_f32	float32	-120.0F	120.0F
	VehSpd_Kph_T_f32	float32	0.0F	511.0F
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350.0F	1350.0F
	VehSpdVld_Cnt_T_logl	boolean	FALSE	TRUE
	RelHwAg_HwDeg_T_f32	float32	-1440.0F	1440.0F
Return Value	FilOneEna_MilliSec_T_lgc	boolean	FALSE	TRUE

Design Rationale

None.

Processing

Refer to the “PinionTqCalc” and “LpFilOneEna” blocks of the Simulink model of the design.

Local Function #4

Function Name	ArbtrtnSmthng	Type	Min	Max
Arguments Passed	FCentrHwConf_Uls_T_f32	float32	0.0F	1.0F
	VehDynHwConf_Uls_T_f32	float32	0.0F	1.0F
	WhlSpdHwConf_Uls_T_f32	float32	0.0F	1.0F
	RelHwAg_HwDeg_T_f32	float32	-1440.0F	1440.0F
	*LrndHwConf_Uls_T_f32	float32	0.0F	1.0F
Return Value	None

Design Rationale

None.

Processing

Please refer to the “Arbitration” and “Smoothing” blocks of the Simulink model of the design.

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 Coding Standards.doc	2.1
5	FDD : SF042A_HwAgSnsrls_Design	See Synergy Sub-project version

16.3 - HwAgSnsrls_Review

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
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. SF042A_HwAgSnsrls_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. SF042A_HwAgSnsrls_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#9330

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

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/27/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi R

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

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

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

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 :

03/27/17

Component Type :

Application

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi R

Shawn Penning

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

HwAgSnsrls.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:

HwAgSnsrls_MDD.docx

Revision:

4

FDD/SCIR/DSR/FDR/CM Name:

SF042A_HwAgSnsrls_Design

Revision:

2.0.0

Quality Check Items:

Rationale is required for all answers of No

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
PolySpace

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

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

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:

Matthew Leser

Review Date :

03/27/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi R

Shawn Penning

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. HwAgSnsrls_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. 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:

Matthew Leser

Review Date :

03/27/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi R

Shawn Penning

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

HwAgSnsrls.c

Source File Revision:

6

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

draft 1.2.0

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:

Matthew Leser

Review Date :

03/27/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi R

Shawn Penning

17 - Component Implementation

Component Implementation

Component Documentation

17.1 - HwAgSysArbn_DesignReview

Overview

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. SF045A_HwAgSysArbn_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. SF045A_HwAgSysArbn_Impl_2.8.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#16783

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 :

11/03/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

Yes

Comments:

versions (If available)

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

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

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

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/03/17

Component Type :

Application

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:

HwAgSysArbn.c

Source File Revision:

10

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:

HwAgSysArbn_MDD.docx

Revision:

7

FDD/SCIR/DSR/FDR/CM Name:

SF045A_HwAgSysArbn_Design

Revision:

2.8.0

Quality Check Items:

Rationale is required for all answers of No

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:

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

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:

Matthew Leser

Review Date :

11/03/17

Lead Peer Reviewer:

Avinash James

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:

HwAgSysArbn_MDD.docx

MDD Revision:

7

Source File Name:

HwAgSysArbn.c

Source File Revision:

10

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

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/03/17

Lead Peer Reviewer:

Avinash James

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:

HwAgSysArbn.c

Source File Revision:

10

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:

Polyspace flags for Dead Code. This is because the switch case uses an input. Default case cannot normally be reached, this is for safety in case input

receives garbage data.

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/03/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

17.2 - HwAgSysArbn_Integration Manual

Integration Manual

For

SF045A HwAgSysArbn

VERSION: 1.0

DATE: 09-07-2015

Prepared By:

Sarika Natu,

KPIT Technologies,

India

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

Revision History

Description	Author	Version	Date
Initial version	Sarika Natu	1.0	09-07-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 Design details of software module 5

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	Software Process Release 04.02.00
2	Software Naming Conventions	Software Process Release 04.02.00
3	Design and Coding standards	Software Process Release 04.02.00
4	FDD – SF045A_HwAgSysArbn_Design	See Synergy sub project 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
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
HwAgSysArbnInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
HwAgSysArbnPer1	None	RTE (2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
HwAgSysArbn_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>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

17.3 - HwAgSysArbn_MDD

Module Design Document

For

HwAgSysArbn

Oct 31, 2017

Prepared By:

Matthew Leser,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Sl. No.	Description	Author	Version	Date
1	Initial Version	Sarika Natu(KPIT Technologies)	1.0	07-Sept-2015
2	SF045A_HwAgSysArbn_Design version 2 implementation	SB	2.0	20-Jun-2016
3	Updated to design version 2.2.0	TATA	3.0	07-Dec-16
4	Updated to design version 2.4.0	KK	4.0	28-Feb-17
5	Updated graph and added new function	ML	5.0	19-Jul-2017
6	Added new function	ML	6.0	11-Oct-2017
7	Updated Graph	ML	7.0	31-Oct-2017

Table of Contents

1.1 Graphical representation of HwAgSysArbn 5

1.2 Data Flow Diagram 5

1.2.1 Component level DFD 5

1.2.2 Function level DFD 5

2 Constant Data Dictionary 6

2.1 Program (fixed) Constants 6

2.1.1 Embedded Constants 6

3 Software Component Implementation 7

3.1 Sub-Module Functions 7

3.1.1 Init: HwAgSysArbn_Init1 7

3.1.1.1 Design Rationale 7

3.1.1.2 Module Outputs 7

3.1.2 Per: HwAgSysArbn_Per1 7

3.1.2.1 Design Rationale 7

3.1.2.2 Store Module Inputs to Local copies 7

3.1.2.3 (Processing of function)……… 7

3.1.2.4 Store Local copy of outputs into Module Outputs 7

3.2 Server Runables 7

3.3 Interrupt Functions 7

3.4 Module Internal (Local) Functions 7

3.4.1 Local Function #1 7

3.4.1.1 Design Rationale 8

3.4.1.2 Processing 8

3.4.2 Local Function #2 8

3.4.2.1 Design Rationale 8

3.4.2.2 Processing 8

3.4.3 Local Function #3 8

3.4.3.1 Design Rationale 8

3.4.3.2 Processing 8

3.5 GLOBAL Function/Macro Definitions 9

4 Known Limitations with Design 10

5 UNIT TEST CONSIDERATION 11

Appendix A References 12

HwAgSysArbn & High-Level Description

The Handwheel angle system arbitration function accepts inputs from the various angle sources available in the EPS system and selects the angle source to be used for the system handwheel angle value. It also provides for compliance compensation of the angle value and determines the angle value and angle validity to be output on the vehicle data bus.

Design details of software module

Graphical representation of HwAgSysArbn

Data Flow Diagram

See FDD.

Component level DFD

See FDD.

Function level DFD

See FDD.

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Refer .m file

Software Component Implementation

Sub-Module Functions

Init: HwAgSysArbnInit1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: HwAgSysArbn_Per1

Design Rationale

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

Function Name	VldtSnsrlsData	Type	Min	Max
Arguments Passed	HwAgSnsrls_HwDeg_T_f32	float32	-1440.0	1440.0
Arguments Passed	HwAgSnsrlsConfIn_Uls_T_f32	float32	0.0	1.0
Return Value	HwAgSnsrlsConf_Uls_T_f32	float32	0.0	1.0

Design Rationale

Done to reduce Path Count

Processing

Refer to the Handwheel signal serial communication arbitration functionality of “VldtSnsrlsData” subsystem in the Simulink model.

Local Function #2

Function Name	HwAgVelSerlCom	Type	Min	Max
Arguments Passed	HwAgCorrdConf_Uls_T_f32	uint8	0	1
	HwAgSnsrlsConf_Uls_T_f32	uint8	0	1
	HwAgCorrd_HwDeg_T_f32	float32	-1440	1440
	HwAgSnsrls_HwDeg_T_f32	float32	-1440	1440
	HwVel_HwRadPerSec_T_f32	float32	-42.0F	42.0F
	PinionVelConf_Uls_T_f32	float32	0.0F	1.0F
	*HwAgStsToSerlCom_Cnt_T_lgc	boolean	FALSE	TRUE
	*HwVelToSerlCom_HwRadPerSec_T_f32	float32	-42.0F	42.0F
Return Value	HwAgToSerlCom_HwDeg_T_f32	float32	-1440	1440

Design Rationale

None

Processing

Refer to the Handwheel signal serial communication arbitration functionality of “HwAgVelSerlCom” subsystem in the Simulink model.

Local Function #3

Function Name	CalcPinionVel	Type	Min	Max
Arguments Passed	HwTq_HwNwtMtr_T_f32	float32	-10.0F	10.0F
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350.0F	1350.0F
	MotVelVld_Cnt_T_logl	boolean	FALSE	TRUE
	PinionAgConf_Uls_T_f32	float32	0.0F	1.0F
	HwAg_HwDeg_T_f32	float32	-1440.0F	1440.0F
	* PinionVel_HwRadPerSec_T_f32	float32	-42.0F	42.0F
	* PinionVelConf_Uls_T_f32	float32	0.0F	1.0F
Return Value	HwVel_HwRadPerSec_T_f32	float32	-42.0F	42.0F

Design Rationale

None

Processing

Refer to the functionality of “CalcPinionVel” subsystem in the Simulink model.

Local Function #4

Function Name	HwPosnSigLoNTCSet	Type	Min	Max
Arguments Passed	HwAgIdptSig_Cnt_T_u08	uint8	0U	2U
Return Value	None

Design Rationale

Done to reduce Path Count.

Processing

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

For the switch case in Per1, the input ‘HwAgIdptSig_Cnt_T_u08’ will need to go out of range to reach default case.

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 Release 04.02.01
3	Software Naming Conventions.doc	2.0
4	Software Design and Coding Standards.doc	2.1
5	SF045A_HwAgSysArbn_Design	See Synergy subproject version

18 - Component Implementation

Component Implementation

Component Documentation

18.1 - HysCmp_DesignReview

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. SF012A_HysCmp_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. Matthew Leser

Work CR ID:

EA4#8871, EA4#8109

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

No

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 :

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

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.

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

Yes

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

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 :

01/11/17

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:

HysCmp.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:

HysCmp_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

SF012A_HysCmp_Design

Revision:

1.2.0

Quality Check Items:

Rationale is required for all answers of No

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.

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:

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

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 :

01/11/17

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:

HysCmp_MDD.docx

MDD Revision:

2

Source File Name:

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

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:

Matthew Leser

Review Date :

01/11/17

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:

HysCmp.c

Source File Revision:

4

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

01/11/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

18.2 - HysCmp_IntegrationManual

Integration Manual

For

HysCmp

VERSION: 1.0

DATE: 04-Aug-2015

Prepared By:

Spandana Balani,

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	04-Aug-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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

Include NxtrFil.h in Rte_UserTypes.h header file

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

Runnable	Scheduling Requirements	Trigger
HysCmpPer1	None	RTE(2ms)

.

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

18.3 - HysCmp_MDD

Module Design Document

For

HysCmp

Jan 04, 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	SB	1.0	04-Aug-2015
Updated per Design vers. 1.2.0	ML	2.0	04-Jan-2017

Table of Contents

2 HysCmp & High-Level Description 6

1.2 Scope 5

3.1 Graphical representation of HysCmp 7

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

5.1.1 Init: HysCmpInit1 10

5.1.2 Per: HysCmpPer1 10

5.2 Server Runables 10

5.3 Interrupt 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 #1 10

5.4.2.1 Design Rationale 10

5.4.2.2 Processing 11

5.4.3 Local Function #1 11

5.4.3.1 Design Rationale 11

5.4.3.2 Processing 11

5.5 GLOBAL Function/Macro Definitions 11

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Introduction

Purpose

Scope

HysCmp & High-Level Description

Refer FDD

Design details of software module

Refer FDD

Graphical representation of HysCmp

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

Refer FDD

Sub-Module Functions

Init: HysCmpInit1

Refer FDD

Per: HysCmpPer1

Refer FDD

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	MoreCmp	Type	Min	Max
Arguments Passed	TqChg_HwNwtMtr_T_f32	Float32	0	20
	*RiseXPtr_HwNwtMtr_T_f32	Float32	0	1
	*RiseXFac_HwNwtMtr_T_f32	Float32	0	1
Return Value	RiseY_Uls_T_f32	Float32	0	1

Design Rationale

None

Processing

Refer ‘MoreCmp’ block in Simulink model

Local Function #1

Function Name	LessCmp	Type	Min	Max
Arguments Passed	TqChg_HwNwtMtr_T_f32	Float32	0	20
	*RiseYPtr_Uls_T_f32	Float32	0	1
	*RiseXFac_HwNwtMtr_T_f32	Float32	0	1
Return Value	RiseY_Uls_T_f32	Float32	0	1

Design Rationale

None

Processing

Refer ‘LessCmp’ block in Simulink model

Local Function #1

Function Name	CalcAvlCmp	Type	Min	Max
Arguments Passed	HwTqFildVal_HwNwtMtr_T_f32	Float32	-10	10
	AssiCmdFildVal_HwNwtMtr_T_f32	Float32	-352	352
Return Value	HysCmpAvl_HwNwtMtr_T_f32	Float32	-8.8	8.8

Design Rationale

None

Processing

Refer ‘CalcAvlCmp’ block in Simulink model

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	Process 04.02.00
5	FDD – SF012A_HysCmp_Design	See Synergy SubProject version

19 - Component Implementation

Component Implementation

Component Documentation

19.1 - ImcSigArbn_IntegrationManual

Integration Manual

For

ImcSigArbn

VERSION: 1.0

DATE: 02-FEB-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 R	1.0	02-FEB-2017

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

Summary Sheet
Synergy Project
Source Code
PolySpace

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 Software Engineering Process 04.02.01
2	EA4 Software Naming Conventions	See Software Engineering Process 04.02.01
3	Software Design and Coding standards	See Software Engineering Process 04.02.01
4	SF063_ImcSigArbn_Design	See Synergy Subroject Version

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

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
ImcSigArbnInit1	None	RTE_Init

Runnable	Scheduling Requirements	Trigger
ImcSigArbnPer1	None	RTE (2 ms)
ImcSigArbnPer2	None	RTE (10 ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
N/A

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

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

None

19.2 - ImcSigArbn_MDD

Module Design Document

For

ImcSigArbn

May 11, 2017

Prepared By:

Krishna Anne,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Shruthi Raghavan	1.0	02/02/2017
Fix for Issues in using Return value of ImcData	Krishna Anne	2.0	05/11/2017

Table of Contents1 Introduction 4

1.1 Purpose 4

2 ImcSigArbn & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of ImcSigArbn 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: ImcSigArbnInit1 8

5.1.1.1 Design Rationale 8

5.1.2 Per: ImcSigArbnPer1 8

5.1.2.1 Design Rationale 8

5.1.3 Per: ImcSigArbnPer2 8

5.1.3.1 Design Rationale 8

5.2 Server Runnables 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 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

Module design document for ImcSigArbn SF063A to refer for design rationale, unit test considerations and implementation details.

ImcSigArbn & High-Level Description

This function shall define the requirements for sharing signals. It shall serve as a single function of contact to obtain information from the other controller in a dual ECU structure. It shall define requirements for arbitration of signals and integrator states to ensure performance.

Design details of software module

Graphical representation of ImcSigArbn

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
Refer to DataDict.m file

Software Component Implementation

Sub-Module Functions

Init: ImcSigArbnInit1

Design Rationale

Refer FDD Simulink model

Per: ImcSigArbnPer1

Design Rationale

Refer FDD Simulink model
The implementation of ElapsedTime block was optimized in the code to avoid a couple of Boolean operations and additional temporary variables. The functionality was verified in peer review with design owner as well.

Per: ImcSigArbnPer2

Design Rationale

Refer FDD Simulink model
The implementation of ElapsedTime block was optimized in the code to avoid a couple of Boolean operations and additional temporary variables. The functionality was verified in peer review with design owner as well.

Server Runnables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	CalcImcSigOffs	Type	Min	Max
Arguments Passed	ImcSigArbnEna_Cnt_T_logl	Boolean	0	1
	InpSig_Uls_T_f32	Float32	-32767.5	32767.5
	ImcSig_Uls_T_f32	Float32	-32767.5	32767.5

	*SigLpFil_Uls_T_str	FilLpRec1	[struct ('FilSt’, -32767.5, 'FilGain', 0. 062831853000000)]	[struct('FilSt', 32767.5, 'FilGain', 0. 998132557254885)]
	*OutSigPrev_Uls_T_f32	Float32	-32767.5	32767.5
	ImcSigArbnSigOffsLim_Uls_T_f32	Float32	0	32767.5
	Sts_Cnt_T_enum	ImcArbnRxSts1	IMCARBNRXSTS_NODATA	IMCARBNRXSTS_INVLD
	Rtn_Cnt_T_enum	Std_ReturnType	E_NOT_OK	E_OK
Return Value	OutSigPrev_Uls_T_f32	Float32	-32767.5	32767.5

Design Rationale

All the ImcSigArbn_* functions in the Per2 inside ‘Calc Offs Corrn 10ms Periodic’ block of FDD do the same function with different cals, pims and input signals. So they were all clubbed into single function.

Local Function #1

Function Name	CalcImcSigOffs	Type	Min	Max
Arguments Passed	SetArbnNtc	float32	0	4294967296
Return Value	NA	NA	NA	NA

Design Rationale

To handle cyclomatic complexity.

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

Filter ranges given in design are full range of float for state variable and [0,max_float32] for gain – this has to be fixed in next version. For now, the ranges are given in the unit test considerations after calculating from the code. These values can be used instead.
The value of calculated float32 offset signals are limited to [-cal, cal] and then later checked for absolute value being greater than or equal to the same cal. This was verified by component owner as not the design intent & one of these places, the cal used has to change.
The input signal PosnTrakgIntgtrSt1 has a range of [-2864,2864] according to the DataDict.m file. If its IMC counterpart ImcPosnTrakgIntgtrSt1 read in Per2 has the same range [-2864,2864], the algorithm inside the ImcSigArbn_PosnTrakgIntglSt1 will only give output PosnTrakgIntgtrSt1Offs values

[Refer: SF063A_ImcSigArbn/ImcSigArbn/ImcSigArbnPer2/Calculate Offs Corrn 10 ms Periodic /ImcSigArbn_PosnTrakgIntglSt1/Do arbitration]
in the range [-2864,2864]. However, the limit used on this value is a calibration ImcSigArbnPosnTrakg1ArbnOffsLim whose range is [0,32767.5], max is much larger than the actual maximum that can be taken by this variable. Also, the output limits on the PosnTrakgIntgtrSt1Offs output is [-32767.5,32767.5], which needs to change.

The units on the embedded constants INTGTROFFSSATNLOWLIM_ULS_F32 and INTGTROFFSSATNUPPRLIM_ULS_F32 need to change if a different set of constants are decided to be used for PosnTrakgIntgtrSt1Offs limits

UNIT TEST CONSIDERATION

In case the m file gives float min/max values as the ranges for the following PIMs, use the values from this table instead as the range.

PIM Variables		Ranges
Structure Name	Structure Element	Min	Max
HwAgLpFil	FilSt	-1440	1440
HwAgLpFil	FilGain	0. 062831853000000	0. 998132557254885
HwAgTarLpFil	FilSt	-1440	1440
HwAgTarLpFil	FilGain	0. 062831853000000	0. 998132557254885
HwTqLpFil	FilSt	-10	10
HwTqLpFil	FilGain	0. 062831853000000	0. 998132557254885
MotVelLpFil	FilSt	-1350	1350
MotVelLpFil	FilGain	0. 062831853000000	0. 998132557254885
PosnServoIntgtrLpFil	FilSt	-32767.5	32767.5
PosnServoIntgtrLpFil	FilGain	0. 062831853000000	0. 998132557254885
PullCmpLongTermCmpLpFil	FilSt	-10	10
PullCmpLongTermCmpLpFil	FilGain	0. 062831853000000	0. 998132557254885
PullCmpShoTermCmpLpFil	FilSt	-10	10
PullCmpShoTermCmpLpFil	FilGain	0. 062831853000000	0. 998132557254885
TrakgIntgtrSt1LpFil	FilSt	-2864	2864
TrakgIntgtrSt1LpFil	FilGain	0. 062831853000000	0. 998132557254885
TrakgIntgtrSt2LpFil	FilSt	-20000	20000
TrakgIntgtrSt2LpFil	FilGain	0. 062831853000000	0. 998132557254885
VehSpdLpFil	FilSt	0	511
VehSpdLpFil	FilGain	0. 062831853000000	0. 998132557254885

Tolerance of state variables can be assumed to be six significant digits and for the gains it is 1e-07.

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	See Software Engineering Process 04.02.01
3	Software Naming Conventions.doc	See Software Engineering Process 04.02.01
4	Software Design and Coding Standards.doc	See Software Engineering Process 04.02.01
5	SF063A_ImcSigArbn_Design	See Synergy Sub-Project Version

19.3 - ImcSigArbn_PeerReviewChecklist

Overview

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. SF063A_ImcSigArbn_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. Avinash James

Work CR ID:

EA4#14396

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

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 :

08/17/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:

ImcSigArbn.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:

ImcSigArbn_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF063A_ImcSigArbn_Design

Revision:

1.3.0

Quality Check Items:

Rationale is required for all answers of No

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

Not done in EA4

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:

Design Rationale for ElapsedTime block is noted in MDD

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:

No header file for this component

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

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

Only division by non-zero embedded constant

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All library functions are used to do these operations

All typecasting and fixed point arithmetic,

Yes

Comments:

including all use of fixed point macros and

All library functions are used to do these operations

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

Yes

Comments:

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

All library functions are used to do these operations

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#9841 Continuous Improvement CR written

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 :

08/17/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:

ImcSigArbn.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 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 :

08/17/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

20 - Component Implementation

Component Implementation

Component Documentation

20.1 - InertiaCmpVel_IntegrationManual

Integration Manual

For

InertiaCmpVel

VERSION: 1.0

DATE: 23-Jul-2015

Prepared By:

Spandana Balani

Nexteer Automotive,

Saginaw, MI, USA

Revision History

: ARM Cortex R4 Memory Usage
Sl. No.	Description	Author	Version	Date
1	Initial version	SB	1.0	23-July-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 4.01.00
<2>	<Software Naming Conventions>	Process 4.01.00
<3>	<Coding standards>	Process 4.01.00
<4>	FDD – SF014A_InertiaCmpVel_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
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
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
InertiaCmpVelInit1	On Init	RTE_Init

Runnable	Scheduling Requirements	Trigger
InertiaCmpVelPer1	None	RTE(2ms)

.

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

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

20.2 - InertiaCmpVel_MDD

Module Design Document

For

InertiaCmpVel

August 18, 2017

Prepared By:

Matthew Leser,

Nexteer Automotive,

Saginaw, MI, USA
Change History

SNo	Description	Author	Version	Date
1	Initial Version	SB	1.0	23-Jul-2015
2	Updated to version 1.3.0 of design	SB	2.0	11-Mar-2016
3	Updated to version 1.7.0 and 1.8.0 of design	KK	3.0	21-Jun-2016
4	Updated to version 1.9.0 of design	KK	4.0	14-Jul-2016
5	Updated Graph and function input	ML	5.0	18-Aug-2017

Table of Contents

2 InertiaCmpVel & High-Level Description 5

3.1 Graphical representation of InertiaCmpVel 6

5.1.1 Sub-Module Functions 9

5.1.2 Interrupt Service Routines 9

5.1.3 Server Runnable Functions 9

5.1.4 Module Internal (Local) Functions 9

5.1.5 Transition Functions 11

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
PolySpace

Introduction

Purpose

Scope

InertiaCmpVel & High-Level Description

Refer FDD

Design details of software module

Graphical representation of InertiaCmpVel

Data Flow Diagram

Component level DFD

Refer FDD

Function level DFD

Refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

None

Global Constants

Refer .m file

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)
typedef struct FilCoeffRec	b0_Uls_f32	Float32	FULL	FULL
	b1_Uls_f32	Float32	FULL	FULL
	b2_Uls_f32	Float32	FULL	FULL
	a0_Uls_f32	Float32	FULL	FULL
	a1_Uls_f32	Float32	FULL	FULL
	a2_Uls_f32	Float32	FULL	FULL

Software Component Implementation

Sub-Module Functions

Initialization sub-module InertiaCmpVelInit1()

Design Rational:

Init function is not present in the model but in reference to the Init.txt text file Low pass filter and Notch filter are initialized.

For Low pass filter standard EA4 LPF implementation from NxtrFil.h is followed and for Notch filter initialization, EA3 implementation is followed.

Periodic sub-module InertiaCmpVelPer1()

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

Calculate Driver Velocity

Function Name	DrvrVelCalc	Type	Min	Max
Arguments Passed	HwTq_HwNwtMtr_T_f32	float32	-10	10
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
	VehSpd_Kph_T_f32	float32	0	511
Return Value	ScadDrvrVel_MotRadPerSec_T_f32	float32	-1350	1350

Calculate ADD Coefficient

Function Name	ADDCoeffCalc	Type	Min	Max
Arguments Passed	AssiCmdBas_MotNwtMtr_T_f32	float32	-8.8	8.8
	WhlImbRejctnAmp_MotNwtMtr_T_f32	float32	0	8.8
	VehSpd_Kph_T_f32	float32	0	511
Return Value	ADDCoeffCalc_MotNwtMtrSpRad_T_f32	float32	0.0	0.00007

Calculate Gain

Function Name	DecelGain	Type	Min	Max
Arguments Passed	VehLgtA_KphPerSec_T_f32	float32	-35	35
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
Return Value	DecelGain_Uls_T_f32	float32	0	1

Calculate Filter Coefficients

Function Name	FilCoeffCalc		Type	Min	Max
Arguments Passed	ADDCoeff_MotNwtMtrPerMotRadPerSec_T_f32		float32	0.0	0.041306
	WhlImbRejctnAmp_MotNwtMtr_T_f32		float32	0	8.8
	VehSpd_Kph_T_f32		float32	0	511
Return Value	*FilCoeff_T_Rec	b0_Uls_f32	float32	-2.74156205240179	0
		b1_Uls_f32	float32	0.0	0.330448
		b2_Uls_f32	float32	-0.160083862455113	2.41111405240179
		a0_Uls_f32	float32	0.5525885	3.9498924
		a1_Uls_f32	float32	-7.9996842	-4.8417266
		a2_Uls_f32	float32	4.0504234	10.6056849

Generate Command

Function Name	GenFddIcCmd		Type	Min	Max
Arguments Passed	ScadDrvrVel_MotRadPerSec_T_f32		float32	-7226.652	7226.652
	*FilCoeff_T_Rec	b0_Uls_f32	float32	-2.74156205240179	0
		b1_Uls_f32	float32	0.0	0.330448
		b2_Uls_f32	float32	-0.166262133009164	2.41111405240179
		a0_Uls_f32	float32	0.5525885	3.9498924
		a1_Uls_f32	float32	-7.9996842	-4.8417266
		a2_Uls_f32	float32	4.0504234	10.6056849
Return Value	InertiaCmp_MotNwtMtr_T_f32		Float	-8.8	8.8

NotchCmp

Function Name	NotchCmp	Type	Min	Max
Arguments Passed	VehSpd_Kph_T_f32	float32	0	511
	InertiaCmp_MotNwtMtr_T_f32	float32	-8.8	8.8
	WhlImbRejctnAmp_MotNwtMtr_T_f32	float32	0	8.8
Return Value	NotchCmp _MotNwtMtr_T_f32	float32	-8.8	8.8

FilNotchFullUpdOutp_f32

Function Name	FilNotchFullUpdOutp_f32	Type	Min	Max
Arguments Passed	Inp	float32	See unit test consideration
	FilNotchStRecPtr	FilNotchStRec1
	FilNotchGainRecPtr	FilNotchGainRec1
Return Value	None

Description

Notch filter output calculation implemented based on ‘Inertia Comp Notch’ block functionality.

FilNotchInit

Function Name	FilNotchInit	Type	Min	Max
Arguments Passed	Inp	float32	See unit test consideration
	FilNotchStRecPtr	FilNotchStRec1
	FilNotchGainRecPtr	FilNotchGainRec1
Return Value	FilOut	float32

Description

Notch filter initialization function implemented based on EA3 design.

Transition Functions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

Since the notch filter implementation used in this module is dynamic in nature, absolute ranges are difficult to determine without pre-defined knowledge on the combination of coefficient values (A1, A2, B0, B1, B2). Because of this, the systems group ran simulations on 10 different combinations of coefficients (2 with defined default calibrations, 8 considered extreme cases of notch filters) and logged the ranges of the filter state variables and outputs during a frequency sweep. The ranges given throughout this module were taken as the worst case results of all of the given test cases.

To provide useful cases for unit testing, the boundary checks tested during unit testing should be altered to test the state variable minimum and maximum for each of the 10 test cases with the given coefficients set to the values given in that test case. In the case where the default values of the coefficients are used in a vector, the unit tester should not test the corresponding state variables with values over the range defined for that set of coefficients. See attached simulation results.

GenFddIcCmd function is designed to work with argument values from the calling function as used with the other functions in the module, and outputs may be out of the expected range if tested with arbitrary combinations of input values. Unit testing of this function should use only passed argument value combinations coming from the calling function.

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 – SF014A_InetiaCmpVel_Design	See Synergy Sub project version

20.3 - InertiaCmpVel_PeerReview

Overview

Sheet 1: Summary Sheet

Rev 7.1

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. SF014A_InertiaCmpVel_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. SF014A_InertiaCmpVel_Impl_1.11.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#14511

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. (Note: If this peer review form was not
completed for pervious versions of this component, the Change Owner should review the entire component and complete the checklist in its entirety prior and check
the form into Syngery. This may be done prior to reviewing the modifications for this Change Result)
- The Change Owner shall responsible for completing the entire checklist (Pre and Group review items) prior holding the initial group review.
- New components should include FDD Owner and Intergator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Select "Yes" and add "N/A" to the comments for checklist items that are not applicable for this change
- 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 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

Prep project is updated from correct basline

Yes

Comments:

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:

Matt Leser

Review Date :

08/18/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Bri Spencer

Sheet 3: Davinci Files

Rev 7.1

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

DCF: Only StdDef Port types are used

Yes

Comments:

DCF: Non-program-specific components saved

N/A

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.

DCF:Automated validation check is performed

Yes

Comments:

DCF: Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

DCF: Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

kzshz2: Intended Use: Identify if all the Sender/Reciever ports are compatibale with there connecting ports. Rationale: This will help to avoid errors when this component is being integrated into a project.

DCF: Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

kzshz2: Intended Use: Identify if all the Server/Client ports are compatibale with there connecting ports. Rationale: This will help to avoid errors when this component is being integrated into a project.

DCF: Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

kzshz2: Intended Use: Identify if all the Sender/Reciever ports are compatibale with there connecting ports. Rationale: This will help to avoid errors when this component is being integrated into a project.

DCF: Calibration port initialization values match

Yes

Comments:

DataDict.m file

kzshz2: Intended Use: Identify if all the Server/Client ports are compatibale with there connecting ports. Rationale: This will help to avoid errors when this component is being integrated into a project.

DCF: All sender/receiver port read/writes using direct

N/A

Comments:

read/writes(List justification of not)

DCF: Runnable calling frequencies match FDD

N/A

Comments:

No changes done

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

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

08/18/17

Component Type :

Application

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Bri Spencer

Sheet 4: Source Code

Rev 7.1

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

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

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

Module Design Document Name:

kzshz2: Intended Use: Identify which version of the MDD this source file was written against. Rationale: Needed for traceability between source code and MDD InertiaCmpVel_MDD

MDD Revision:

kzshz2: Intended Use: Identify which version of the MDD this source file was written against. Rationale: Needed for traceability between source code and MDD 5

FDD/SCIR/DSR/FDR/CMS Revision:

nz63rn: Intended Use: Identify which version of which FDD/CMS/SER this source file was written against. Rationale: Needed for traceability between source code and FDD/CMS/SER SF014A_InertiaCmpVel_Design_1.14.0

nz63rn: Intended Use: Identify which version of which FDD/CMS/SER this source file was written against. Rationale: Needed for traceability between source code and FDD/CMS/SER

Quality Check Items:

Rationale is required for all answers of No

Software Design and Coding Standards 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

All source code changes have Requirements Tracability

N/A

Comments:

tags in the component

No Variables are declared at the Module 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:

No Compiler Errors or Warnings verified

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:

Is component.h included

N/A

Comments:

Are all includes actually needed? System includes

Yes

Comments:

only allowed in Nexteer library components

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, function parameters

N/A

Comments:

to

All execution-order-dependent code can be

N/A

Comments:

recognized by the compiler: [N80]

No possibility of a non-terminating loop: [N63]

N/A

Comments:

No possibility of divide by zero: [N65]

N/A

Comments:

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]

No possibility of converting a negative floating

Yes

Comments:

point value to an unsigned type: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

No possibility of dereferencing a null

N/A

Comments:

pointer: [N70]

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

No violations of other coding standard rules

Yes

Comments:

identified during review

Incorrect items that require FDD changes

N/A

Comments:

ie (display variables used incorrectly, limiting on outputs,

NvM struct types, divide by zero, other?)

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:

Matt Leser

Review Date :

08/18/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Bri Spencer

Sheet 5: MDD

Rev 7.1

8-Jun-15

Peer Review Meeting Log (MDD Review)

Module Name:

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

Module

kzshz2: Intended Use: Identify how many source files are being reviewed and trace it to the appropriate MDD. Rationale: Required for traceability between source code and MDD

1

of

1

MDD Revision:

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

Source File Revision:

kzshz2: Intended Use: Identify which version of the source file was this MDD written for. Rationale: Needed for traceability between source code and MDD 8

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

High-level Diagrams have been reviewed

Yes

Comments:

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all module input and output

N/A

Comments:

data not communicated through RTE ports, per

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

All other Design rationale understood and captured

N/A

Comments:

appropriately

All Unit Test Considerations have beeen 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:

Matt Leser

Review Date :

08/18/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Bri Spencer

Sheet 6: PolySpace

Rev 7.1

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Module Name:

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

Source File Revision:

8

Module

1

of

1

Compliance Guidelines Version:

01.03.00

kzshz2: Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner. Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed Brief Summary of Changes (In Results or Tool):

Quality Check Items:

Rationale is required for all answers of No

Contract Folder's header files are appropriate

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 MISRA Compliance Guidelines

Yes

Comments:

Are previously added suppression comments still

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

Yes

Comments:

appropriate

Cyclomatic complexity and Static path count ok per

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

Yes

Comments:

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:

Matt Leser

Review Date :

08/18/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Bri Spencer

21 - Component Implementation

Component Implementation

Component Documentation

21.1 - LimrCdng_IntegrationManual

Integration Manual

For

LimrCdng

VERSION: 1.0

DATE: 22-Jul-2015

Prepared By:

Nick Saxton,

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	N. Saxton	1.0	22-Jul-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 LimrCdng High-Level Description 4

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	2.0
2	Software Design and Coding Standards	2.1
3	SF038A LimrCdng FDD	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
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 .m file in FDD

Required Global Data Outputs

Refer .m file in FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
None

Runnable	Scheduling Requirements	Trigger
LimrCdngPer1	None	RTE (2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

21.2 - LimrCdng_MDD

Module Design Document

For

LimrCdng

July 22, 2015

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.0	22-Jul-2015

Table of Contents

2.1 Graphical representation of LimrCdng 5

4.1.1 Sub-Module Functions 7

4.1.2 Interrupt Service Routines 7

4.1.3 Server Runnable Functions 7

4.1.4 Module Internal (Local) Functions 7

4.1.5 Transition Functions 7

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

Appendix C References 12

LimrCdng High-Level Description

This function provides a layer of protection from erroneous signals feeding into SF04 Sum & Limit. It is applied primarily to limiting signals that serve to reduce motor torque command under certain operating conditions. This function can prevent step response or toggling behavior that might cause undesirable vehicle feel. It includes fault injection capability at some inputs to facilitate tuning.

Design details of software module

Refer FDD

Graphical representation of LimrCdng

Data Flow Diagram

Refer FDD

Component level DFD

N/A

Function level DFD

N/A

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Refer .m file

Software Component Implementation

Sub-Module Functions

Initialization sub-module {_Init()}

None

Periodic sub-module {LimrCdngPer1}

Refer FDD

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

None

Transition Functions

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 (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	SF038A LimrCdng FDD	See Synergy subproject version

21.3 - LimrCdng_PeerReview

Overview

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. SF038A_LimrCdng_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#853

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:

Nick Saxton

Review Date :

07/31/15

Lead Peer Reviewer:

Spandana

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sankar

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:

Initial version

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:

LimrCdngTqIncSlewY should be Ary1D_u13p3_2 - Done 8/3/15

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:

No display variables

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:

Nick Saxton

Review Date :

07/31/15

Component Type :

Application

Lead Peer Reviewer:

Spandana

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sankar

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

LimrCdng.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:

LimrCdng_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF038A_LimrCdng_Design_1.0.0

Revision:

1

Quality Check Items:

Rationale is required for all answers of No

for variable names

Yes

Comments:

Cal tables need '_u9p7/u13p3' at end of names - Done 7/31/15

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

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,

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

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 :

07/31/15

Lead Peer Reviewer:

Spandana

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sankar

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

LimrCdng_MDD.docx

MDD Revision:

1

Source File Name:

LimrCdng.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:

Nick Saxton

Review Date :

07/31/15

Lead Peer Reviewer:

Spandana

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sankar

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

LimrCdng.c

Source File Revision:

1

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

Yes

Comments:

Compliance Guideline

Refer comments

Are previously added justification and deviation

N/A

Comments:

Initial version

comments still appropriate

Do all MISRA deviation comments use approved

No

Comments:

deviation tags

Refer comments

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:

11.5 warning appears to be a bug in polyspace because the 'const' qualifier is retained
12.3 warnings on 'sizeof' are because the cals appear in contract file as functions
19.11 warning is evaluated and code is OK. Deviation comments to be added after the approved Deviation tag and Rationale are added to the MISRA deviation list

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 :

07/31/15

Lead Peer Reviewer:

Spandana

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sankar

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. LimrCdng_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 :

07/31/15

Lead Peer Reviewer:

Spandana

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sankar

22 - Component Implementation

Component Implementation

Component Documentation

22.1 - LoaMgr_IntegrationManual

Integration Manual

For

LoaMgr

VERSION: 1.0

DATE: 06-Oct-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	Matthew Leser	1.0	06-Oct-2017

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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

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

Exclusive Area ‘LoaMgrExclusiveArea’ must be configured to block OS interrupts.

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

Runnable	Scheduling Requirements	Trigger
LoaMgrPer1	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

22.2 - LoaMgr_MDD

Module Design Document

For

LoaMgr

October 6, 2017

Prepared By:

Matthew Leser

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	Matthew Leser	1	06-Oct-2017

Table of Contents1 Introduction 5

2 LoaMgr High-Level Description 6

3.1 Graphical representation of LoaMgr 7

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

5.1.1 Init: LoaMgrInit1 10

5.1.1.1 Design Rationale 10

5.1.1.2 Module Outputs 10

5.1.2 Per: LoaMgrPer1 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.2 Server Runables 10

5.3 Interrupt Functions 10

5.4.1 Local Function #1 10

5.4.1.1 Design Rationale 10

5.4.1.2 Processing 11

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.4.6 Local Function #6 12

5.4.6.1 Design Rationale 12

5.4.6.2 Processing 12

5.4.7 Local Function #7 12

5.4.7.1 Design Rationale 12

5.4.7.2 Processing 13

5.4.8 Local Function #8 13

5.4.8.1 Design Rationale 13

5.4.8.2 Processing 13

5.5 GLOBAL Function/Macro Definitions 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

Introduction

Purpose

MDD for Loss of Assist Manager

LoaMgr High-Level Description

Refer to FDD

Design details of software module

Graphical representation of LoaMgr

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
Refer .m file

Software Component Implementation

Sub-Module Functions

Init: LoaMgrInit1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: LoaMgrPer1

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

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	LtchInp	Type	Min	Max
Arguments Passed	IdptSig_Cnt_T_u08	uint8	0	4
	MaxAllwdVal_Cnt_T_u08	uint8	2	4
	*PrevVal_Cnt_T_u08	uint8	0	4
Return Value	HwTqResp_Cnt_T_u08	uint8	0	4

Design Rationale

None

Processing

Refer to ‘Latch_Inputs’ block in FDD at ‘SF049B_LoaMgr/LoaMgr/LoaMgrPer1/Latch_Inputs’

Local Function #2

Function Name	CntMtgtnReq	Type	Min	Max
Arguments Passed	HwTqLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
	MotAgLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
	CurrMeasLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
	IvtrLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
Return Value	MultiMtgtnResp_Cnt_T_u08	uint8	0	3

Design Rationale

None

Processing

Refer to ‘CntMtgtnReq’ block in FDD at ‘SF049B_LoaMgr/LoaMgr/LoaMgrPer1/Arbitrate_Responses/CntSwBasdMtgtn/CntMtgtnReq’

Local Function #3

Function Name	ReqHwTqResp	Type	Min	Max
Arguments Passed	HwTqIdptMin_Cnt_T_u08	uint8	0	4
	TqLoaAvl_Cnt_T_lgc	boolean	FALSE	TRUE
Return Value	HwTqResp_Cnt_T_u08	uint8	0	5

Design Rationale

None

Processing

Refer to ‘HwTqResp’ block in FDD at ‘SF049A_LoaMgr/LoaMgr/LoaMgrPer1/Request_Responses’

Local Function #4

Function Name	ReqMotAgResp	Type	Min	Max
Arguments Passed	MotAgIdptMin_Cnt_T_u08	uint8	0	3
	MotAgSnsrlsAvl_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	MotAgResp_Cnt_T_u08	uint8	0	5

Design Rationale

None

Processing

Refer to ‘MotAgResp’ block in FDD at ‘SF049A_LoaMgr/LoaMgr/LoaMgrPer1/Request_Responses’

Local Function #5

Function Name	ReqCurrMeasResp	Type	Min	Max
Arguments Passed	CurrMeasIdptMin_Cnt_T_u08	uint8	0	2
Return Value	CurrMeasResp_Cnt_T_u08	uint8	0	5

Design Rationale

None

Processing

Refer to ‘CurrMeasResp’ block in FDD at ‘SF049A_LoaMgr/LoaMgr/LoaMgrPer1/Request_Responses’

Local Function #6

Function Name	ReqInvtrResp	Type	Min	Max
Arguments Passed	IvtrIdptMin_Cnt_T_u08	uint8	0	2
Return Value	InvtrResp_Cnt_T_u08	uint8	0	5

Design Rationale

None

Processing

Refer to ‘CurrMeasResp’ block in FDD at ‘SF049A_LoaMgr/LoaMgr/LoaMgrPer1/Request_Responses’

Local Function #7

Function Name	CntSwBasdMtgtnChk	Type	Min	Max
Arguments Passed	Resp_Cnt_T_u08	uint8	0	5
	PrevMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
Return Value	MtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE

Design Rationale

None

Processing

This function corresponds to common logic (for all requests) in ‘CntSwBasdMtgtn’ block in FDD at ‘SF049A_LoaMgr/LoaMgr/LoaMgrPer1/Arbitrate_Responses’

Local Function #8

Function Name	SelFinalResp	Type	Min	Max
Arguments Passed	MultiMtgtnResp_Cnt_T_u08	uint8	0	5
	HwTqResp_Cnt_T_u08	uint8	0	5
	MotAgResp_Cnt_T_u08	uint8	0	5
	CurrMeasResp_Cnt_T_u08	uint8	0	5
	InvtrResp_Cnt_T_u08	uint8	0	5
Return Value	LoaSt_Cnt_T_enum	LoaSt1	0	5

Design Rationale

None

Processing

This function corresponds to ‘SelFinalResp’ block in FDD at ‘SF049A_LoaMgr/LoaMgr/LoaMgrPer1/Arbitrate_Responses’

Local Function #9

Function Name	SetFaults	Type	Min	Max
Arguments Passed	LoaSt_Cnt_T_enum	LoaSt1	0	5
	HwTqIdptMin_Cnt_T_u08	uint8	0	4
	MotAgIdptMin_Cnt_T_u08	uint8	0	3
	CurrMeasIdptMin_Cnt_T_u08	uint8	0	2
	IvtrIdptMin_Cnt_T_u08	uint8	0	2
Return Value	None

Design Rationale

None

Processing

This function corresponds to ‘Set_Faults’ block in FDD at ‘SF049A_LoaMgr/LoaMgr/LoaMgrPer1’

Local Function #10

Function Name	SwMtgtnEn	Type	Min	Max
Arguments Passed	HwTqLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
	MotAgLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
	CurrMeasLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
	IvtrLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
	VehSpeedMod_Cnt_T_enum	enum	STEERMOD_BASEPS	STEERMOD_FULLYATNMS
	*LoaSca_Uls_T_f32	float32	0	1
	*LoaRateLim_UlsPerSec_T_f32	float32	0.01	500
Return Value	None

Design Rationale

None

Processing

This function corresponds to ‘SwMtgtn’ block in FDD at ‘SF049A_LoaMgr/LoaMgr/LoaMgrPer1/Assign_Scale’.

Note that ‘*LoaSca_Uls_T_f32’ and ‘*LoaRateLim_UlsPerSec_T_f32’ are the outputs of this function.

Local Function #11

Function Name	LoaMgrCoder	Type	Min	Max
Arguments Passed	CurrMeasLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
	IvtrLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
	FetLoaMtgtnEna_Cnt_T_lgc	boolean	FALSE	TRUE
Return Value	MotAndThermProtnLoaMod_Cnt_T_u08	uint8	0	7

Design Rationale

None

Processing

This function corresponds to ‘coder block in FDD at ‘SF049B_LoaMgr/LoaMgr/LoaMgrPer1/coder’ .

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

To satisfy IF case inside function ‘LtchInp’, out of range values will need to be given for values passed to function.

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 : SF049B_LoaMgr_Design	See Synergy sub project version

22.3 - LoaMgr_Review

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
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. SF049B_LoaMgr_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. SF049B_LoaMgr_Impl_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#14942

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:

ICR EA4#16526 was submitted to update design to add Exclusive Area. This was not done before because SF049B was created before update was done to SF049A.

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 :

10/25/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Pratik J

Brendon Binder

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.

Initital 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

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 :

10/25/17

Component Type :

Application

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Pratik J

Brendon Binder

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

LoaMgr.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:

LoaMgr_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF049B_LoaMgr_Design

Revision:

1.0.0

Quality Check Items:

Rationale is required for all answers of No

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

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:

Matthew Leser

Review Date :

10/25/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Pratik J

Brendon Binder

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

LoaMgr_MDD.docx

MDD Revision:

1

Source File Name:

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

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 :

10/25/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Pratik J

Brendon Binder

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. LoaMgr_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 :

10/25/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Pratik J

Brendon Binder

Sheet 7: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

LoaMgr.c

Source File Revision:

1

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

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:

Code Prover flags for Dead Code. This is done intentionally for Safety Purpose.

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 :

10/25/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Pratik J

Brendon Binder

23 - Component Implementation

Component Implementation

Component Documentation

23.1 - MotCtrlPrmEstimn_IntegrationManual

Integration Manual

For

MotCtrlPrmEstimn

VERSION: 1.0

DATE: 20-JUN-2015

Prepared By:

Rijvi Ahmed

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	20-Jun-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1.1 Non RTE NvM Blocks 10

1.2 RTE NvM Blocks 10

2 Compiler Settings 11

2.1 Preprocessor MACRO 11

2.2 Optimization Settings 11

3 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 4.00.00
<2>	<Software Naming Conventions>	Process 4.00.00
<3>	<Coding standards>	Process 4.00.00
<4>	FDD – SF102A_MotCtrlPrmEstimn_Design	See Synergy Subproject version
	<Add if more available>

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

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

Runnable	Scheduling Requirements	Trigger
MotCtrlPrmEstimnPer1	None	RTE(2ms)
MotCtrlPrmEstimnPer2	None	RTE(100ms)
GetMotPrmNomEol_Oper	None	On event
SetMotPrmNomEol_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

Non RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

RTE NvM Blocks

Block Name

MotPrmNom

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

23.2 - MotCtrlPrmEstimn_MDD

Module Design Document

For

MotCtrlPrmEstimn

VERSION: 4.0

DATE: 25-Sep-2017

Prepared By:

TATA,

Trivandrum, India

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	1.0	20-JUN-2015
2	Updated per design rev. 1.5.0	Rijvi	2.0	07-APRIL-2016
3	Updated per design rev. 2.1.0	ML	3.0	29-NOV-2016
4	New Input added MotAndThermProtnLoaMod and deleted IvtrLoaMtgtnEna	TATA	4.0	25-SEP-2017

Table of Contents

3 MotCtrlPrmEstimn & High-Level Description 7

4.1 Graphical representation of MotCtrlPrmEstimn 8

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

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

6.1.2 Module specific Lookup Tables Constants 11

7 Software Module Implementation 12

7.1 Sub-Module Functions 12

7.2 Initialization Functions 12

7.2.1 Per: MotCtrlPrmEstimnInit1 12

7.2.1.1 Design Rationale 12

7.2.1.2 Store Module Inputs to Local copies 12

7.2.1.3 (Processing of function)……… 12

7.2.1.4 Store Local copy of outputs into Module Outputs 12

7.3 PERIODIC FUNCTIONS 12

7.3.1 Per: MotCtrlPrmEstimnPer1 12

7.3.1.1 Design Rationale 12

7.3.1.2 Store Module Inputs to Local copies 12

7.3.1.3 (Processing of function)……… 12

7.3.1.4 Store Local copy of outputs into Module Outputs 12

7.3.2 Per: MotCtrlPrmEstimnPer2 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 13

7.4 Non PERIODIC FUNCTIONS 13

7.5 Interrupt Functions 13

7.6 Server runnables 13

7.6.1 GetMotPrmNomEol 13

7.6.1.1 Design Rationale 13

7.6.1.2 Store Module Inputs to Local copies 13

7.6.1.3 (Processing of function)……… 13

7.6.1.4 Store Local copy of outputs into Module Outputs 13

7.6.2 SetMotPrmNomEol 13

7.6.2.1 Design Rationale 13

7.6.2.2 Store Module Inputs to Local copies 13

7.6.2.3 (Processing of function)……… 13

7.6.2.4 Store Local copy of outputs into Module Outputs 13

7.7 Serial Communication Functions 14

7.8 Local Function/Macro Definitions 14

7.8.1 Local Function #1 CalcCurrMagSqRef 14

7.9 GLObAL Function/Macro Definitions 14

7.10 TRANSIENT FUNCTIONS 14

8 Unit Test Considerations 15

9 Known Limitations With Design 16

10 Appendix 17

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 4.02.00
<2>	<Software Naming Conventions>	Process 4.02.00
<3>	<Coding standards>	2.1
<4>	FDD - SF102A_MotCtrlPrmEstimn_Design	See Synergy Subproject version
	<Add if more available>

MotCtrlPrmEstimn & High-Level Description

Please refer FDD

Design details of software module

Graphical representation of MotCtrlPrmEstimn

Data Flow Diagram

Module level DFD

Sub-Module level DFD

COMPONENT FLOW DIAGRAM

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
N/A	<(Variable name qualified Refer[2])>	<Define the value >

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

< All program specific constants will be defined in detail >

Local

Constant Name	Resolution	Units	Value
Refer constants from .m file
BITMASK2_CNT_U08	1	Cnt	2U

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

None

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
None

Software Module Implementation

Sub-Module Functions

NONE

Initialization Functions

Per: MotCtrlPrmEstimnInit1

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

PERIODIC FUNCTIONS

Per: MotCtrlPrmEstimnPer1

Design Rationale

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

Per: MotCtrlPrmEstimnPer2

Design Rationale

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

Non PERIODIC FUNCTIONS

None

Interrupt Functions

None

Server runnables

GetMotPrmNomEol

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

See GetMotPrmNomEol block in the FDD

Store Local copy of outputs into Module Outputs

None

SetMotPrmNomEol

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

See SetMotPrmNomEol block in the FDD

Store Local copy of outputs into Module Outputs

None

Serial Communication Functions

None

Local Function/Macro Definitions

Local Function #1 CalcCurrMagSqRef

None

GLObAL Function/Macro Definitions

None

TRANSIENT FUNCTIONS

None

Unit Test Considerations

None

Known Limitations With Design

CurrMeasLoaMtgtnEna and FetLoaMtgtnEna are terminated. These flags need not be computed at all.

Appendix

None

23.3 - MotCtrlPrmEstimn_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. SF102A_MotCtrlPrmEstimn_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. SF102A_MotCtrlPrmEstimn_Impl_3.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. Ramachandran M G (TATA ELXSI)

Work CR ID:

EA4#13239

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:

Krishna Anne

Review Date :

10/11/17

Lead Peer Reviewer:

Avinash

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn

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)

NA for the changes

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:

NA for the changes

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

NA for the changes

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:

Ramachandran (TATA)

Review Date :

10/11/17

Component Type :

Application

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash

Shawn

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

MotCtrlPrmEstimn.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:

MotCtrlPrmEstimn_MDD.doc

Revision:

4

FDD/SCIR/DSR/FDR/CM Name:

SF102A_MotCtrlPrmEstimn_Design

Revision:

3.0.0

Quality Check Items:

Rationale is required for all answers of No

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
PolySpace

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:

Please see design limitation in the MDD

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

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

Please see design limitation in the MDD

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:

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:

Ramachandran(TATA)

Review Date :

10/11/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash

Shawn

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

MotCtrlPrmEstimn_MDD.doc

MDD Revision:

4

Source File Name:

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

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

Yes

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:

Ramachandran

Review Date :

10/11/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash

Shawn

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

MotCtrlPrmEstimn.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 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:

Ramachandran(TATA)

Review Date :

10/11/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Avinash

Shawn

24 - Component Implementation

Component Implementation

Component Documentation

24.1 - MotCurrPeakEstimn_DesignReview

Overview

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. SF108A_MotCurrPeakEstimn_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. SF108A_MotCurrPeakEstimn_Impl_3.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. Ramachandran(Tata Elxsi)

Work CR ID:

EA4#13247

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:

Only reviewed 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 :

10/09/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

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

NA for the changes

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

NA for the changes

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:

NA for the changes

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

NA for the changes

Component is correct component type

Yes

Comments:

General Notes / Comments:

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:

Ramachandran(Tata elxsi)

Review Date :

10/09/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

MotCurrPeakEstimn.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:

MotCurrPeakEstimn_MDD.docx

Revision:

4

FDD/SCIR/DSR/FDR/CM Name:

SF108A_MotCurrPeakEstimn_Design

Revision:

3.0.0

Quality Check Items:

Rationale is required for all answers of No

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.

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

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]

Only for the changes

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:

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:

Ramachandran(Tata Elxsi)

Review Date :

10/09/17

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:

MotCurrPeakEstimn_MDD.docx

MDD Revision:

4

Source File Name:

MotCurrPeakEstimn.c

Source File Revision:

5

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:

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:

Ramachandran(Tata Elxsi

Review Date :

10/09/17

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:

MotCurrPeakEstimn.c

Source File Revision:

5

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

Previous implementation issue are present

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:

Ramachandran(Tata Elxsi)

Review Date :

10/09/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

24.2 - MotCurrPeakEstimn_IntegrationManual

Integration Manual

For

MotCurrPeakEstimn

VERSION: 1.0

DATE: 04-Aug-2015

Prepared By:

Spandana Balani,

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	04-Aug-2015

Table of Contents

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

3 Dependencies 7

3.1 SWCs 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 – SF108A_MotCurrPeakEstimn_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

Include NxtrFil.h in Rte_UserTypes.h header file

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

Runnable	Scheduling Requirements	Trigger
MotCurrPeakEstimnPer1	None	RTE(2ms)
MotCurrPeakEstimnPer2	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

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

24.3 - MotCurrPeakEstimn_MDD

Module Design Document

For

MotCurrPeakEstimn

Sep 25, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

TATA,

Trivandrum, India

Change History

Description	Author	Version	Date
Initial Version	SB	1.0	05-Aug-2015
Updated graphical representation due to changes from FDD v1.2.0	NS	2.0	25-Apr-2016
Updated to FDD v2.0.0	JK	3.0	18-Nov-2016
Updated to FDD v3.0.0	TATA	4.0	25-Sep-2017

Table of Contents

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 MotCurrPeakEstimn & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of MotCurrPeakEstimn 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: MotCurrPeakEstimnInit1 8

5.1.2 Per: MotCurrPeakEstimnPer1 8

5.1.3 Per: MotCurrPeakEstimnPer2 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

Purpose

Scope

MotCurrPeakEstimn & High-Level Description

Refer FDD

Design details of software module

Refer FDD

Graphical representation of MotCurrPeakEstimn

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
BITMASK1_CNT_U08	uint8	CNT	1U
BITMASK2_CNT_U08	uint8	CNT	2U
BITMASK4_CNT_U08	uint8	CNT	4U

Software Component Implementation

Refer FDD

Sub-Module Functions

Init: MotCurrPeakEstimnInit1

Refer FDD

Per: MotCurrPeakEstimnPer1

Refer FDD

Per: MotCurrPeakEstimnPer2

Refer 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

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	Process 04.02.00
5	FDD – SF108A_MotCurrPeakEstimn_Design	See Synergy SubProject version

25 - Component Implementation

Component Implementation

Component Documentation

25.1 - MotCurrRegCfg_IntegrationManual

Integration Manual

For

MotCurrRegCfg

VERSION: 1.0

DATE: <02-JUN-2015>

Prepared By:

Selva Sengottaiyan

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	02-Jun-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 4.00.00
<2>	<Software Naming Conventions>	Process 4.00.00
<3>	<Coding standards>	Process 4.00.00
<4>	FDD – SF104A_MotCurrRegCfg_Design	See Synergy Subproject version
	<Add if more available>

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

Constants	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
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
MotCurrRegCfgInit1	None	RTE

Runnable	Scheduling Requirements	Trigger
MotCurrRegCfgPer1	None	RTE(2ms)

.

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

25.2 - MotCurrRegCfg_MDD

Module Design Document

For

MotCurrRegCfg

VERSION: 5.0

DATE: 25-Sep-2017

Prepared By:

Software Group

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	02-JUN-2015
2	Updated per design rev. 1.3.0	Rijvi	2.0	12-Mar-2016
3	Updated per design rev. 1.4.0	Krishna	3.0	29-Apr-2016
4	Updated per design rev. 2.1.0	JK	4.0	11-Nov-2016
5.	Updated per design rev. 3.0.0	TATA	5.0	25-Sep-2017

Table of Contents

3 MotCurrRegCfg & High-Level Description 7

4.1 Graphical representation of MotCurrRegCfg 8

7.2 Initialization Functions 11

7.2.1 Per: MotCurrRegCfgINIT1 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 Per: MotCurrRegCfgper1 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 Non PERIODIC FUNCTIONS 11

7.5 Interrupt Functions 11

7.6 Serial Communication Functions 12

7.7 Local Function/Macro Definitions 12

7.8 GLObAL Function/Macro Definitions 12

7.9 TRANSIENT FUNCTIONS 12

8 Unit Test Considerations 13

9 Known Limitations With Design 14

10 UNIT TEST CONSIDERATION 15

11 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>	<Coding standards>	Process 04.02.01
<4>	FDD - SF104A_MotCurrRegCfg_Design	See Synergy Subproject version
	<Add if more available>

MotCurrRegCfg & High-Level Description

Design details of software module

Graphical representation of MotCurrRegCfg

Data Flow Diagram

Module level DFD

Sub-Module level DFD

COMPONENT FLOW DIAGRAM

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	<(Variable name qualified Refer[2])>	<Define the value >

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

< All program specific constants will be defined in detail >

Local

Constant Name	Resolution	Units	Value
Refer constants from .m file

Global

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

Constant Name

Refer constants from .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 .m file

Software Module Implementation

Sub-Module Functions

NONE

Initialization Functions

Per: MotCurrRegCfgINIT1

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

PERIODIC FUNCTIONS

Per: MotCurrRegCfgper1

Design Rationale

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

Non PERIODIC FUNCTIONS

None

Interrupt Functions

None

Serial Communication Functions

None

Local Function/Macro Definitions

None

GLObAL Function/Macro Definitions

None

TRANSIENT FUNCTIONS

None

Unit Test Considerations

None

Known Limitations With Design

None

UNIT TEST CONSIDERATION

The range of the application data type used for the calibration MotCurrRegCfgMotClsdLoopBwDaxY and MotCurrRegCfgMotNatFrqQaxY are not updated per the DataDict.m file changes. We moved away using the application data type, hence it has no impact.

Appendix

None

25.3 - MotCurrRegCfg_Review

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. SF104A_MotCurrRegCfg_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. SF104A_MotCurrRegCfg_Impl_3.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. TATA Offshore

Work CR ID:

EA4#13243

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:

Krishna Anne

Review Date :

10/18/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

Yes

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:

TATA

Review Date :

10/18/17

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:

MotCurrRegCfg.c

Source File Revision:

9

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:

MotCurrRegCfg_MDD.doc

Revision:

5

FDD/SCIR/DSR/FDR/CM Name:

SF104_MotCurrRegCfg_Design

Revision:

2.3.1

Quality Check Items:

Rationale is required for all answers of No

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

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

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

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:

TATA

Review Date :

10/18/17

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:

MotCurrRegCfg_MDD.doc

MDD Revision:

6

Source File Name:

MotCurrRegCfg.c

Source File Revision:

8

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

N/A

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:

TATA

Review Date :

10/18/17

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:

MotCurrRegCfg.c

Source File Revision:

9

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:

TATA

Review Date :

10/18/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

26 - Component Implementation

Component Implementation

Component Documentation

26.1 - MotCurrRegVltgLimr_Integration Manual

Integration Manual

For

‘MotCurrRegVltgLimr’

VERSION: 1.0

DATE: 26-May-2015

Prepared By:

Selva Sengottaiyan

Nexteer Automotive,

Saginaw, MI, USA

Revision History

: ARM Cortex R4 Memory Usage
Sl. No.	Description	Author	Version	Date
1	Initial version	Selva Sengottaiyan	1.0	4-June-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

Summary Sheet
Synergy Project
Davinci Files
Source Code
Source Code (2)
MDD
PolySpace

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 – SF105A_MotCurrRegVltgLimr_Design	See Synergy sub project version
2	Software Naming Conventions	Process 4.00.00
3	Software Design and Coding Standards	Process 4.00.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

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotCurrRegVltgLimrInit1	None	Init

Runnable	Scheduling Requirements	Trigger
MotCurrRegVltgLimrPer1		Motor Control 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
<Memmap usuage info>

Non RTE NvM Blocks

Block Name
None

RTE NvM Blocks

Block Name
none

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None

Appendix

None

26.2 - MotCurrRegVltgLimr_MDD

Module Design Document

For

‘MotCurrRegVltgLimr’

VERSION: 5.0

DATE: 08-Nov-2017

Prepared By:

TATA ELXSI,

TRIVANDRUM, INDIA

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	26-May-2015
2	Updated graphical representation and added local function information	Nick Saxton	2.0	13-Apr-2016
3	Updated for FDD v2.1.0	Matthew Leser	3.0	7-Nov-2016
4	Updated to fix Anomaly EA4#9045	Matthew Leser	4.0	04-Jan-2017
5	Updated for FDD v3.0.0	TATA	5.0	08-Nov-2017

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation 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: MotCurrRegVltgLimrInit1 11

7.1.1.1.1 Design Rationale 11

7.1.1.1.2 Module Outputs 11

7.1.1.1.3 Module Internal 11

7.1.2 PERIODIC FUNCTIONS 11

7.1.2.1 INIT: MotCurrRegVltgLimrPER1 11

7.1.2.1.1 Design Rationale 11

7.1.2.1.2 Module Outputs 11

7.1.3 Interrupt Functions 11

7.1.4 Server runnables 12

7.1.4.1.1 Store Local copy of outputs into Module Outputs 12

7.1.5 Local Function/Macro Definitions 12

7.1.5.1.1 Local function #1 12

7.1.5.1.2 Local function #2 12

7.1.5.1.3 Local function #3 12

7.1.5.1.4 Local function #4 13

7.1.5.1.5 Local function #5 13

7.1.6 GLObAL Function/Macro Definitions 13

7.1.7 Tranisition FUNCTIONS 13

8 Known Limitations With Design 14

9 UNIT TEST CONSIDERATION 15

10 Appendix 16

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	MDD Guidelines	Process 4.02.01
2	Software Naming Conventions	Process 4.02.01
3	Software Design and Coding standards	2.1
4	FDD – SF105A_MotCurrRegVltgLimr_Design	See Synergy sub project version

High-Level Description

None

Design details of software module

Graphical representation

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
MODIDXHILIM_VOLT_F32	Single precision float	Volt	1
MODIDXLOLIM_VOLT_F32	Single precision float	Volt	0
BITMASK1_CNT_U08	Uint8	CNT	1U
BITMASK2_CNT_U08	Uint8	CNT	2U
BITMASK4_CNT_U08	Uint8	CNT	4U

Global

Constant Name

Module specific Lookup Tables Constants

None

Software Module Implementation

Sub-Module Functions

Initialization Functions

MotCurrRegVltgLimrInit1

INIT: MotCurrRegVltgLimrInit1

Design Rationale

Design follows implemenetation in FDD.

Module Outputs

Refer ‘MotCurrRegVltgLimrInit’ block in FDD

Module Internal

None

PERIODIC FUNCTIONS

INIT: MotCurrRegVltgLimrPER1

Design Rationale

Module Outputs

As per FDD, dMotCurrRegVltgLimrMotVltgDecouplFbDax, dMotCurrRegVltgLimrMotVltgDecouplFbQax renamed with dMotCurrRegVltgLimrMotVltgDecoupldFbDax, dMotCurrRegVltgLimrMotVltgDecouplFbQax in the source file. And also dMotCurrRegVltgLimrMotCurrCmdErr(display variable) is nowhere used in source file. That variable davinci definition is removed. Design follows implemenetation in FDD.

Interrupt Functions

None

Server runnables

None

Store Local copy of outputs into Module Outputs

None

Local Function/Macro Definitions

Local function #1

Function Name	KpKiCtrl	Type	Min	Max
Arguments Passed	MotPropGain_Ohm_T_f32	Float32	0	2.25
	MotIntglGain_Ohm_T_f32	Float32	0	3.6
	SysSt_Cnt_T_enum	Enum	SYSST_DI	SYSST_WRMININ
	CmdErr_Ampr_T_f32	Float32	-200	400
	*MotVltgIntglCmdPrev_Volt_T_f32	Float32	-1000	1000
	*MotCurrRegVltgLimrMotVltgPropCmd_Volt_T_f32	Float32	-26.5	26.5
	*MotCurrRegVltgLimrMotVltgIntglPreLim_Volt_T_f32	Float32	-26.5	26.5
	MotVltgIntglLoLim_Volt_T_f32	Float32	-31	0
	MotVltgIntglHiLim_Volt_T_f32	Float32	0	31
	*MotVltgPropCmd_Volt_T_f32	Float32	-26.5	26.5
	*MotVltgIntglCmd_Volt_T_f32	Float32	6	26.5

* MotVltgPropCmd_Volt_T_f32 and * MotVltgIntglCmd_Volt_T_f32 are outputs of this function.

Local function #2

Function Name	ErrorCalcQax	Type	Min	Max
Arguments Passed	QaxCurrCmd_Ampr_T_f32	Float32	-200	200
	QaxRplCmd_Ampr_T_f32	Float32	-29	29
	QaxCoggCmd_Ampr_T_f32	Float32	-6	6
	QaxCurrModif_Ampr_T_f32	Float32	-200	200
	* QaxCmdFinal_Ampr_T_f32	Float32	-200	200
Returns	CmdErrQax_Ampr_T_f32	Float32	-200	400

*QaxCmdFinal_Ampr_T_f32 is also an output of this function.

Local function #3

Function Name	LoaScaFac	Type	Min	Max
Arguments Passed	CurrLoaMtgtnEn_Cnt_T_logl	Boolean	FALSE	TRUE
	IvtrLoaMtgtnEn_Cnt_T_logl	Boolean	FALSE	TRUE
	MotCtrlDualEcuMotCtrlMtgtnEna_Cnt_T_logl	Boolean	FALSE	TRUE
	FetLoaMtgtnEna_Cnt_T_logl	Boolean	FALSE	TRUE
	*CurrLoaScaFac_Uls_T_f32	Float32	0	1
	*IvtrLoaScaFac_Uls_T_f32	Float32	0	1
	*DualEcuScaFac_Uls_T_f32	Float32	0	1
	*FetScaFac_Uls_T_f32	Float32	0.0F	1.0F

*CurrLoaScaFac_Uls_T_f32, *IvtrLoaScaFac_Uls_T_f32, and *DualEcuScaFac_Uls_T_f32 are outputs of this function.

Local function #4

Function Name	MotCurr_Pred	Type	Min	Max
Arguments Passed	MotInduQaxEstimdIvs_IvsHenry_T_f32	Float32	2240	33334
	MotREstimd_Ohm_T_f32	Float32	0.005	0.12565
	CurrQax_Ampr_T_f32	Float32	-200	200
	MotVltgQaxPrev_Volt_T_f32	Float32	-26.5	26.5
	CurrDax_Ampr_T_f32	Float32	-200	200
	MotVltgDaxPrev_Volt_T_f32	Float32	-26.5	26.5
	MotBackEmfVltg_Volt_T_f32	Float32	-101.25	101.25
	ReacncQax_Ohm_T_f32	Float32	-0.5	0.5
	ReacncDax_Ohm_T_f32	Float32	-0.5	0.5
	MotInduDaxEstimdIvs_IvsHenry_T_f32	Float32	2240	33334
	MotCurrRegVltgLimrMotCurrPredEna_Cnt_T_f32	Boolean	FALSE	TRUE
	MotCtrlCurrPredTi_NanoSec_T_f32	Float32	0	125000
	*MotCurrQaxPred_Ampr_T_f32	Float32	-200	200
	*MotCurrDaxPred_Ampr_T_f32	Float32	-200	200

*MotCurrQaxPred_Ampr_T_f32 and *MotCurrDaxPred_Ampr_T_f32 are outputs of this function.

Local function #5

Function Name	Decoder	Type	Min	Max
Arguments Passed	MotAndThermProtnLoaMod_Cnt_T_u08	Uint8	OU	255U
	CurrMeasLoaMtgtnEna_Cnt_T_logl	Boolean	FALSE	TRUE
	IvtrLoaMtgtnEna_Cnt_T_logl	Boolean	FALSE	TRUE
	FetLoaMtgtnEna_Cnt_T_logl	Boolean	FALSE	TRUE

* CurrMeasLoaMtgtnEna_Cnt_T_logl, *IvtrLoaMtgtnEna_Cnt_T_logl, *FetLoaMtgtnEna_Cnt_T_logl are outputs of this function.

GLObAL Function/Macro Definitions

None

Tranisition FUNCTIONS

None

Known Limitations With Design

None

UNIT TEST CONSIDERATION

None

Appendix

None

26.3 - MotCurrRegVltgLimr_Peer Review Checklists

Overview

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. SF105A_MotCurrRegVltgLimr_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. SF105A_MotCurrRegVltgLimr_Impl_3.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. Ramachandran (TATA Elxsi)

Work CR ID:

EA4#13245

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:

ICR# 15310 has been submitted to fix issues found in .m file that do not affect functionality.

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:

Ramachandran (TATA Elxsi)

Review Date :

11/08/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)

N/A for change

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

N/A for change

for fixed point types

Calibration port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

MotRefMdlIvtrDeadTiBrdgVltgSca value changed 0 to1

for fixed point types

Earlier implementation it was wrongly initialized with 0

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:

Ramachandran (TATA Elxsi)

Review Date :

11/14/17

Component Type :

CDD

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:

CDD_MotCurrRegVltgLim.c

Source File Revision:

7

Header File Name:

CDD_MotCurrRegVltgLimr.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:

MotCurrRegVltgLimr_MDD.docx

Revision:

5

FDD/SCIR/DSR/FDR/CM Name:

SF105A_MotCurrRegVltgLimr_Design

Revision:

3.0.0

Quality Check Items:

Rationale is required for all answers of No

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

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

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

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

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

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:

Ramachandran (TATA Elxsi)

Review Date :

11/14/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: Source Code (2)

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotCurrRegVltgLim_MotCtrl.c

Source File Revision:

12

Header File Name:

CDD_MotCurrRegVltgLimr.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:

MotCurrRegVltgLimr_MDD.docx

Revision:

5

FDD/SCIR/DSR/FDR/CM Name:

SF105A_MotCurrRegVltgLimr_Design

Revision:

3.0.0

Quality Check Items:

Rationale is required for all answers of No

Summary Sheet
Synergy Project
Davinci Files
Source Code
MDD
PolySpace

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

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

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

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:

Ramachandran (TATA Elxsi)

Review Date :

11/14/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:

MotCurrRegVltgLimr_MDD.docx

MDD Revision:

5

Source File Name:

CDD_MotCurrRegVltgLim.c

Source File Revision:

7

Source File Name:

CDD_MotCurrRegVltgLim_MotCtrl.c

Source File Revision:

12

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

Yes

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:

Ramachandran (TATA Elxsi)

Review Date :

11/14/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Other Reviewer(s):

Sheet 7: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_MotCurrRegVltgLim_MotCtrl.c

Source File Revision:

12

Source File Name:

CDD_MotCurrRegVltgLim.c

Source File Revision:

7

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

Unreachable code in previous implementation

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:

Ramachandran (TATA Elxsi)

Review Date :

11/08/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

x`

27 - Component Implementation

Component Implementation

Component Documentation

27.1 - MotQuadDetn Review

Overview

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. SF101A_MotQuadDetn_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. SF101A_MotQuadDetn_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#11065

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 :

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

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

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:

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:

MotQuadDetn.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:

MotQuadDetn_MDD.doc

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

SF101A_MotQuadDetn_Design

Revision:

1.2.1

Quality Check Items:

Rationale is required for all answers of No

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:

Tags Removed

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

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:

Shawn Penning

Review Date :

06/21/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

MotQuadDetn_MDD.docx

MDD Revision:

2

Source File Name:

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

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

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

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

MotQuadDetn.c

Source File Revision:

2

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

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 :

06/21/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Brionna Spencer

27.2 - MotQuadDetn_IntegrationManual

Integration Manual

For

MOTOR QUADRANT DETECTION

VERSION: 1.0

DATE: 11-MAY-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	Spandana Balani	1.0	11-May-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 – SF101A Motor Quadrant Detection	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

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
MotQuadDetnInit1	On Init	Rte_Init

Runnable	Scheduling Requirements	Trigger
MotQuadDetnPer1	None	RTE 2ms Task

.

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

27.3 - MotQuadDetn_MDD

Module Design Document

For Motor Quadrant Detection

VERSION: 1.0

DATE: 11-MAY-2015

Prepared By:

Shawn Penning

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	11-May-2015
2	Update to Unit Test Considerations	SPP	2.0	16-Jun-2017

Table of Contents

3 motquaddetn & High-Level Description 7

4.1 Graphical representation of MOtquaddetn 8

7.1.1 Initialization Functions 11

7.1.1.1 INIT: MotQuadDetnInit1 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: MotQuadDetnPer1 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.2 Interrupt Functions 11

7.3 Serial Communication Functions 12

7.4 Local Function/Macro Definitions 12

7.5 GLObAL Function/Macro Definitions 12

7.6 TRANSIENT FUNCTIONS 12

8 Known Limitations With Design 13

9 UNIT TEST CONSIDERATION 14

10 Appendix 15

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 3.06.00
<2>	<Software Naming Conventions>	Process 3.06.00
<3>	<Coding standards>	Process 3.06.00
<4>	FDD – SF101A Motor Quadrant Detection	See Synergy Subproject version
	<Add if more available>

motquaddetn & High-Level Description

None

Design details of software module

Graphical representation of MOtquaddetn

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

N/A

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
Refer constants from .m file

Global

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

Constant Name
N/A

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 Constant name qualified in [2]>	<Refer MDD guidelines [1]>	<Refer MDD guidelines [1]>	<Refer MDD guidelines [1]>

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

INIT: MotQuadDetnInit1

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

PERIODIC FUNCTIONS

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

Per: MotQuadDetnPer1

Design Rationale

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

Interrupt Functions

None

Serial Communication Functions

None

Local Function/Macro Definitions

None

GLObAL Function/Macro Definitions

None

TRANSIENT FUNCTIONS

None

Known Limitations With Design

Rollover Checking is not needed. Fixed point math implementation takes care of it and no additional logic is required.

UNIT TEST CONSIDERATION

Rollovers should not occur in normal operation in the vehicle, however, rollovers will most likely occur during dynamometer testing or other tests. (From Motor Control FDD REPS GG4500 BMW 5.3.doc)

Appendix

None

28 - Component Implementation

Component Implementation

Component Documentation

28.1 - MotRefMdl_DesignReview

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. SF103A_MotRefMdl_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. SF103A_MotRefMdl_Impl_4.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. TATA ELXSI

Work CR ID:

EA4#13241

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:

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

10/20/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

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

NA for the changes

Calibration port initialization values match

N/A

Comments:

DataDict.m file

NA for the changes

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

NA for the changes

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

NA for the changes

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

NA for the changes

Component is correct component type

Yes

Comments:

General Notes / Comments:

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:

TATA ELXSI

Review Date :

10/09/17

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:

MotRefMdl.c

Source File Revision:

7

Header File Name:

MotRefMdl.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:

MotRefMdl_MDD.doc

Revision:

5

FDD/SCIR/DSR/FDR/CM Name:

SF103A_MotRefMdl_Design

Revision:

4.0.0

Quality Check Items:

Rationale is required for all answers of No

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

Removed earlier ones as well

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

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

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

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:

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:

TATA ELXSI

Review Date :

10/09/17

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:

MotRefMdl_MDD.doc

MDD Revision:

5

Source File Name:

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

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:

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:

TATA ELXSI

Review Date :

10/09/17

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:

MotRefMdl.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 NA

QAC version:

Windows User: eg 8.1.1-R NA

QAC sub project version:

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

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:

TATA ELXSI

Review Date :

10/09/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

28.2 - MotRefMdl_IntegrationManual

Integration Manual

For

MotRefMdl

VERSION: 1.0

DATE: 16-JUN-2015

Prepared By:

Selva Sengottaiyan

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	16-Jun-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 4.00.00
<2>	<Software Naming Conventions>	Process 4.00.00
<3>	<Coding standards>	Process 4.00.00
<4>	FDD – SF103A_MotRefMdl_Design	See Synergy Subproject version
	<Add if more available>

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

Constants	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
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
MotRefMdlInit1	None	RTE

Runnable	Scheduling Requirements	Trigger
MotRefMdlPer1	None	RTE(2ms)

.

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

Module Design Document

For

MotRefMdl

VERSION: 5.0

DATE: 25-Sep-2017

Prepared By:

TATA,

Trivandrum, India

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	12-JUN-2015
2	Updated per design rev. 1.2.0	Rijvi	2.0	13-Mar-2016
3	Updated as per v1.3.0 of FDD	Krishna	3.0	29-Apr-16
4.	Updated as per v2.3.0 of FDD	Krishna	4.0	15-Nov-2016
5.	Updated as per v4.0.0 of FDD	TATA	5.0	25-Sep-2017

Table of Contents

3 MotRefMdl & High-Level Description 7

4.1 Graphical representation of MotRefMdl 8

7.2 Initialization Functions 11

7.2.1 Per: MotRefMdlINIT1 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 Per: MotRefMdlper1 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 Non PERIODIC FUNCTIONS 11

7.5 Interrupt Functions 11

7.6 Serial Communication Functions 12

7.7 Local Function/Macro Definitions 12

7.7.1 Local Function #1 CalcCurrMagSqRef 12

7.7.1.1 Description 12

7.7.2 Local Function #2 CalcIq 12

7.7.2.1 Description 12

7.7.3 Local Function #3 CurrtoVoltTest 12

7.7.3.1 Description 12

7.7.4 Local Function #4 CalcMinMotCurr 12

7.7.4.1 Description 13

7.7.5 Local Function #5 CalcTq 13

7.7.5.1 Description 13

7.7.6 Local Function #6 CalcMaxTqPt 13

7.7.6.1 Description 13

7.7.7 Local Function #7 PrbcIntrpn 13

7.7.7.1 Description 13

7.7.8 Local Function #7 PrbcIntrpn 13

7.7.8.1 Description 14

7.8 GLObAL Function/Macro Definitions 14

7.9 TRANSIENT FUNCTIONS 14

8 Unit Test Considerations 15

9 Known Limitations With Design 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>	Process 04.02.01
<2>	<Software Naming Conventions>	Process 04.02.01
<3>	<Coding standards>	Process 04.02.01
<4>	FDD - SF103A_MotRefMdl_Design	See Synergy Subproject version
	<Add if more available>

MotRefMdl & High-Level Description

Design details of software module

Graphical representation of MotRefMdl

Data Flow Diagram

Module level DFD

Sub-Module level DFD

COMPONENT FLOW DIAGRAM

Variable Data Dictionary

User defined typedef definition/declaration

Typedef Name	Element Name	User Defined Type	Legal Range (min)	Legal Range (max)
MotInterCalcnsRec	RelncTqCoeff_Henry_f32	Single Precision float	3e-05	0.00041
	MotREstimd_Ohm_f32	Single Precision float	0.005	0.12565
	ReacncDaxOverR_Uls_f32	Single Precision float	-14.4436	+14.4436
	ReacncQaxOverR_Uls_f32	Single Precision float	-14.4436	+14.4436
	EgOverR_Ampr_f32	Single Precision float	-200	200
	VltgOverR_Ampr_f32	Single Precision float	-200	200
	VovrRAllSqd_AmprSqd_f32	Single Precision float	0	40000
	EgOverROverZ_Ampr_f32	Single Precision float	-200	200
	VovrRovrZ_Ampr_f32	Single Precision float	-200	200
	MotKeEstimd_VoltPerMotRadPerSec_f32	Single Precision float	.025	.075

Variable definition for enumerated types

Enum Name	Element Name	Value
N/A	<(Variable name qualified Refer[2])>	<Define the value >

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value
MOTVLTGDAXEFLOLIM_VOLT_F32	Single precision float	Volt	-26.5F
MOTVLTGDAXEFHILIM_VOLT_F32	Single precision float	Volt	26.5F
MOTVLTGQAXEFLOLIM_VOLT_F32	Single precision float	Volt	-26.5F
MOTVLTGQAXEFHILIM_VOLT_F32	Single precision float	Volt	26.5F
BITMASK1_CNT_U08	1	Cnt	1U
BITMASK2_CNT_U08	1	Cnt	2U
BITMASK4_CNT_U08	1	Cnt	4U
Refer constants from .m file

Global

Constant Name

Refer constants from .m file

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
Refer .m file

Software Module Implementation

Sub-Module Functions

NONE

Initialization Functions

Per: MotRefMdlINIT1

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

PERIODIC FUNCTIONS

Per: MotRefMdlper1

Design Rationale

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

Non PERIODIC FUNCTIONS

None

Interrupt Functions

None

Serial Communication Functions

None

Local Function/Macro Definitions

Local Function #1 CalcCurrMagSqRef

Function Name	CalcCurrMagSqRef	Type	Min	Max
Arguments Passed	CurrDaxRef_Ampr_T_f32	float32	-200	200
	CurrQaxRef_Ampr_T_f32	float32	-200	200
Return Value	CurrMagSqRef_AmprSq_T_f32	float32	0	40000

Description

Refer FDD (F_CalcIqCommand)

Local Function #2 CalcIq

Function Name	CalcIq	Type	Min	Max
Arguments Passed	Tqcmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	CurrDaxRef_Ampr_T_f32	float32	-200	200
	MotRefMdlInterCalcns_T_str	struct	Refer Struct Definition in Sec5.1	Refer Struct Definition in Sec5.1
Return Value	CurrQaxRefTmp_Ampr_T_f32	float32	-200	200

Description

Refer FDD (F_CalcIqCommand)

Local Function #3 CurrtoVoltTest

Function Name	CalcIq	Type	Min	Max
Arguments Passed	CurrQaxRef_Ampr_T_f32	float32	-8.8	8.8
	CurrDaxRef_Ampr_T_f32	float32	-200	200
	MotRefMdlInterCalcns_T_str	struct	Refer Struct Definition in Sec5.1	Refer Struct Definition in Sec5.1
Return Value	VdR_Ampr_T_f32	float32	-200	200
	VqR_Ampr_T_f32	float32	-200	200
	CurrQaxRefTmp_Ampr_T_f32	float32	-200	200

Description

Refer FDD ( F_ItoV)

Local Function #4 CalcMinMotCurr

Function Name	CalcMinMotCurr	Type	Min	Max
Arguments Passed	MotTqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	MotRefMdlInterCalcns_T_str	struct	Refer Struct Definition in Sec5.1	Refer Struct Definition in Sec5.1
Return Value	CurrQaxMin_Ampr_T_f32	float32	-200	200
	CurrDaxMin_Ampr_T_f32	float32	-200	200
	ImSqrMin_AmprSq_T_f32	float32	0	40000

Description

Refer FDD (Locate Reference)

Local Function #5 CalcTq

Function Name	CalcTq	Type	Min	Max
Arguments Passed	CosDelta_Cnt_T_f32	float32	-1	1
	SinDelta_Cnt_T_f32	float32	-1	1
	MotRefMdlInterCalcns_T_str	struct	Refer Struct Definition in Sec5.1	Refer Struct Definition in Sec5.1
Return Value	TqCalc_MotNwtMtr_T_f32	float32	-8.8	8.8
	CurrDaxMax_Ampr_T_f32	float32	-200	200

Description

Refer FDD (CalculateTorque)

Local Function #6 CalcMaxTqPt

Function Name	CalcMaxTqPt	Type	Min	Max
Arguments Passed	MotTqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	MotRefMdlInterCalcns_T_str	struct	Refer Struct Definition in Sec5.1	Refer Struct Definition in Sec5.1
Return Value	MotTqCmdLimd_MotNwtMtr_T_f32	float32	-8.8	8.8
	CurrDaxMax_Ampr_T_f32	float32	-200	200

Description

Refer FDD (LocateTorqueExtremes)

Local Function #7 PrbcIntrpn

Function Name	PrbcIntrpn	Type	Min	Max
Arguments Passed	IntrpnPts_T_f32	float32	Full range	Full range
Return Value	ParaIntpol_Uls_T_f32	float32	Full range	Full range

Description

Refer FDD ( Parabolic Interpolations)

Local Function #7 PrbcIntrpn

Function Name	Decoder	Type	Min	Max
Arguments Passed	MotAndThermProtnLoaMod_Cnt_T_u08	Uin8	0	255
Return Value	CurrMeasLoaMtgtnEna_Cnt_T_logl	Boolean	FALSE	TRUE
	IvtrLoaMtgtnEna_Cnt_T_logl	Boolean	FALSE	TRUE
	FetLoaMtgtnEna_Cnt_T_logl	Boolean	FALSE	TRUE

Description

Refer FDD ( Decoder)

GLObAL Function/Macro Definitions

None

TRANSIENT FUNCTIONS

None

Unit Test Considerations

None

Known Limitations With Design

None

Appendix

None

29 - Component Implementation

Component Implementation

Component Documentation

29.1 - MotRplCoggCfg_IntegrationManual

Integration Manual

For

MotRplCoggCfg

VERSION: 1

DATE: 09-Feb-2016

Prepared By:

Selva Sengottaiyan

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	S. Sengottaiyan	1.0	09-Feb-2016

Table of Contents

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

4 Dependencies 7

4.1 SWCs 7

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

5 Configuration REQUIREMeNTS 8

5.1 Build Time Config 8

5.2 Configuration Files to be provided by Integration Project 8

5.3 Da Vinci Parameter Configuration Changes 8

5.4 DaVinci Interrupt Configuration Changes 8

5.5 Manual Configuration Changes 8

6 Integration DATAFLOW REQUIREMENTS 9

6.1 Required Global Data Inputs 9

6.2 Required Global Data Outputs 9

6.3 Specific Include Path present 9

7 Runnable Scheduling 10

8 Memory Map REQUIREMENTS 11

8.1 Mapping 11

8.2 Usage 11

8.3 RTE NvM Blocks 11

9 Compiler Settings 12

9.1 Preprocessor MACRO 12

9.2 Optimization Settings 12

10 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	FDD – SF106_MotRplCoggCfg_Impl	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

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 .m file

Required Global Data Outputs

Refer .m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotRplCoggCfgInit1	None	Rte

Runnable	Scheduling Requirements			Trigger
MotRplCoggCfgPer1		None	RTE(2ms)
SetMotRplCoggPrm_Oper		None	On server invocation call
GetMotRplCoggPrm_Oper		None	On server invocation call

.

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
None

Table 1: ARM Cortex R4 Memory Usage

RTE NvM Blocks

Block Name

MotRplCoggPrm

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

29.2 - MotRplCoggCfg_MDD

Module Design Document

For

MotRplCoggCfg

Feb 9, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Selva Sengottaiyan

Nexteer Automotive,

Saginaw, MI, USA
Change History

Version	Description	Author	Date
1	Initial Version	Selva Sengottaiyan	09-Feb-2016

Table of Contents

2 MotRplCoggCfg & High-Level Description 6

3.1 Graphical representation of MotRplCoggCfg 7

5.1.1 Init: MotRplCoggCfgInit1 9

5.1.2 Per: MotRplCoggCfgPer1 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2.1 GetMotRplCoggPrm_Oper 9

5.2.1.1 Design Rationale 9

5.2.1.2 Store Module Inputs to Local copies 10

5.2.1.3 (Processing of function)……… 10

5.2.1.4 Store Local copy of outputs into Module Outputs 10

5.3 Module Internal (Local) Functions 10

5.3.1 Local Function #1 10

5.3.1.1 Design Rationale 10

5.3.1.2 Processing 10

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Introduction

Refer the Design Subproject.

MotRplCoggCfg & High-Level Description

Refer the Design Subproject.

Design details of software module

Graphical representation of MotRplCoggCfg

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 the Design Subproject.	Refer the Design Subproject.	Refer the Design Subproject.	Refer the Design Subproject.

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

Design Rationale

Refer the Design Subproject

Module Outputs

Refer the Design Subproject

Per: MotRplCoggCfgPer1

Design Rationale

Refer the Design Subproject

Store Module Inputs to Local copies

Refer the Design Subproject

(Processing of function)………

Refer the Design Subproject

Store Local copy of outputs into Module Outputs

Refer the Design Subproject

Server Runables

GetMotRplCoggPrm_Oper

Design Rationale

Refer the Design Subproject

Store Module Inputs to Local copies

Refer the Design Subproject

(Processing of function)………

Refer the Design Subproject

Store Local copy of outputs into Module Outputs

Refer the Design Subproject

Module Internal (Local) Functions

Local Function #1

Function Name	CalcCoggTqTbl	Type	Min	Max
Arguments Passed	None

Return Value	None

Design Rationale

Processing

Init function and SetMotRplCoggPrm_Oper updates the Per Instance Memory from Calibrations and NVM values.

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

29.3 - MotRplCoggCfg_ReviewChecklists

Overview

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. SF106A_MotRplCoggCfg_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. SF106A_MotRplCoggCfg_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#5702

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:

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

05/17/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

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

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:

Krishna Anne

Review Date :

05/17/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:

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

MDD Name:

MotRplCoggCfg_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF106A_MotRplCoggCfg_Design

Revision:

1.5.0, 1.6.0

Quality Check Items:

Rationale is required for all answers of No

for variable names

N/A

Comments:

for constant names

Yes

Comments:

for function names

N/A

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

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

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,

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]

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 :

05/17/16

Lead Peer Reviewer:

Nick Saxton

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:

MotRplCoggCfg.c

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

05/17/16

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

29.4 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
SF106A	28	MotRplCoggCfg.c	MotRplCoggCfgPer1	754	I
SF106A	115	MotRplCoggCfg.c	MotRplCoggCfgPer1	744	I
SF106A	61	MotRplCoggCfg.c	MotRplCoggCfgPer1	659-667	I
SF106A	81	MotRplCoggCfg.c	MotRplCoggCfgPer1	496-511	I
SF106A	27	MotRplCoggCfg.c	MotRplCoggCfgPer1	479	I
SF106A	48	MotRplCoggCfg.c	MotRplCoggCfgPer1	757	I
SF106A	49	MotRplCoggCfg.c	MotRplCoggCfgPer1	759	I
SF106A	46	MotRplCoggCfg.c	MotRplCoggCfgPer1	753	I
SF106A	47	MotRplCoggCfg.c	MotRplCoggCfgPer1	756	I
SF106A	44	MotRplCoggCfg.c	MotRplCoggCfgPer1	484	I
SF106A	45	MotRplCoggCfg.c	MotRplCoggCfgPer1	483	I
SF106A	42	MotRplCoggCfg.c	MotRplCoggCfgPer1	480	I
SF106A	43	MotRplCoggCfg.c	MotRplCoggCfgPer1	481	I
SF106A	41	MotRplCoggCfg.c	MotRplCoggCfgPer1	482	I
SF106A	77	MotRplCoggCfg.c	MotRplCoggCfgPer1	752	I
SF106A	72	MotRplCoggCfg.c	MotRplCoggCfgPer1	686-729	I
SF106A	71	MotRplCoggCfg.c	MotRplCoggCfgPer1	670-679	I
SF106A	70	MotRplCoggCfg.c	MotRplCoggCfgPer1	681-734	I
SF106A	79	MotRplCoggCfg.c	MotRplCoggCfgPer1	487-491	I
SF106A	39	MotRplCoggCfg.c	MotRplCoggCfgPer1	478	I
SF106A	33	MotRplCoggCfg.c	GetMotRplCoggPrm_Oper,MotRplCoggCfgInit1	299-309,365	I
SF106A	54	MotRplCoggCfg.c	MotRplCoggCfgPer1	739-749	I
SF106A	56	MotRplCoggCfg.c	MotRplCoggCfgInit1,MotRplCoggCfgPer1	348-364,740-750	I
SF106A	51	MotRplCoggCfg.c	MotRplCoggCfgPer1	755	I
SF106A	50	MotRplCoggCfg.c	MotRplCoggCfgPer1	758	I
SF106A	52	MotRplCoggCfg.c	MotRplCoggCfgPer1	476-761	I
SF106A	32	MotRplCoggCfg.c	MotRplCoggCfgInit1,SetMotRplCoggPrm_Oper	347-363,801-813	I

30 - Component Implementation

Component Implementation

Component Documentation

30.1 - MotRplCoggCmd_IntegrationManual

Integration Manual

For

MotRplCoggCmd

VERSION: 1

DATE: 09-Feb-2016

Prepared By:

Selva Sengottaiyan

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	S. Sengottaiyan	1.0	09-Feb-2016

Table of Contents

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

4 Dependencies 7

4.1 SWCs 7

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

5 Configuration REQUIREMeNTS 8

5.1 Build Time Config 8

5.2 Configuration Files to be provided by Integration Project 8

5.3 Da Vinci Parameter Configuration Changes 8

5.4 DaVinci Interrupt Configuration Changes 8

5.5 Manual Configuration Changes 8

6 Integration DATAFLOW REQUIREMENTS 9

6.1 Required Global Data Inputs 9

6.2 Required Global Data Outputs 9

6.3 Specific Include Path present 9

7 Runnable Scheduling 10

8 Memory Map REQUIREMENTS 11

8.1 Mapping 11

8.2 Usage 11

8.3 RTE NvM Blocks 11

9 Compiler Settings 12

9.1 Preprocessor MACRO 12

9.2 Optimization Settings 12

10 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	FDD – SF107_MotRplCoggCmd_Impl	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

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 .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
MotRplCoggCmdInit1	None	Rte

Runnable	Scheduling Requirements			Trigger
MotRplCoggCmdPer1		Schedule before current regulator	MotorControl *2
SetMotCoggCmdPrm_Oper		None	On server invocation call
GetMotCoggCmdPrm_Oper		None	On server invocation call

.

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
None

Table 1: ARM Cortex R4 Memory Usage

RTE NvM Blocks

Block Name

MotCoggCmdY

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

30.2 - MotRplCoggCmd_MDD

Module Design Document

For

MotRplCoggCmd

Mar 23, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA
Change History

Version	Description	Author	Date
1	Initial Version	Selva Sengottaiyan	09-Feb-2016
2	Updated Unit Test consideration	Avinash James	23-Mar-2017

Table of Contents

2 MotRplCoggCmd & High-Level Description 6

3.1 Graphical representation of MotRplCoggCmd 7

5.1.1 Init: MotRplCoggCmdInit1 9

5.1.2 Per: MotRplCoggCmdPer1 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2.1 GetMotCoggCmdPrm_Oper 9

5.2.1.1 Design Rationale 9

5.2.1.2 Store Module Inputs to Local copies 10

5.2.1.3 (Processing of function)……… 10

5.2.1.4 Store Local copy of outputs into Module Outputs 10

5.2.1 SetMotCoggCmdPrm_Oper 10

5.2.1.1 Design Rationale 10

5.2.1.2 Store Module Inputs to Local copies 10

5.2.1.3 (Processing of function)……… 10

5.2.1.4 Store Local copy of outputs into Module Outputs 10

5.3 Module Internal (Local) Functions 10

5.3.1 Local Function #1 10

5.3.1.1 Design Rationale 10

5.3.1.2 Processing 10

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace

Introduction

Refer the Design Subproject.

MotRplCoggCmd & High-Level Description

Refer the Design Subproject.

Design details of software module

Graphical representation of MotRplCoggCmd

Refer the Design Subproject.

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 the Design Subproject.	Refer the Design Subproject.	Refer the Design Subproject.	Refer the Design Subproject.

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

Design Rationale

Refer the Design Subproject

Module Outputs

Refer the Design Subproject

Per: MotRplCoggCmdPer1

Design Rationale

Refer the Design Subproject- ARCHGLBPRM_ONEOVER2PI constant has been used from ArchGlbPrm.h file instead of ONEOVER2PI which is defined in the FDD

Store Module Inputs to Local copies

Refer the Design Subproject

(Processing of function)………

Refer the Design Subproject

Store Local copy of outputs into Module Outputs

Refer the Design Subproject

Server Runables

GetMotCoggCmdPrm_Oper

Design Rationale

Refer the Design Subproject

Store Module Inputs to Local copies

Refer the Design Subproject

(Processing of function)………

Refer the Design Subproject

Store Local copy of outputs into Module Outputs

Refer the Design Subproject

SetMotCoggCmdPrm_Oper

Design Rationale

Refer the Design Subproject

Store Module Inputs to Local copies

Refer the Design Subproject

(Processing of function)………

Refer the Design Subproject

Store Local copy of outputs into Module Outputs

Refer the Design Subproject

Module Internal (Local) Functions

Local Function #1

Function Name	SinLookup	Type	Min	Max
Arguments Passed	Theta_Rad_T_f32	Float32	0	2*PI

Return Value	Result_Uls_T_f32	Float32	0	1

Design Rationale

Processing

Refer the design

Known Limitations with Design

None

UNIT TEST CONSIDERATION

Abbreviations and Acronyms

In the file CDD_MotRplCoggCmd_MotCtrl.c ARCHGLBPRM_ONEOVER2PI constant has been used from ArchGlbPrm.h file instead of ONEOVER2PI which is defined in the FDD. The architecture has changed to include the constant ONEOVER2PI in the architecture global parameter list as ARCHGLBPRM_ONEOVER2PI 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.0

30.3 - MotRplCoggCmd_ReviewChecklists

Overview

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. SF107A_MotRplCoggCmd_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. SF107A_MotRplCoggCmd_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. Avinash James

Work CR ID:

EA4#10664

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

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:

Avinash James

Review Date :

03/23/17

Lead Peer Reviewer:

Shruthi Raghavan

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_MotRplCoggCmd_MotCtrl.c

Source File Revision:

5

Header File Name:

CDD_MotRplCoggCmd_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

CDD_MotRplCoggCmd.h

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:

MotRplCoggCmd_MDD

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

SF107AMotRplCoggCmd_Design

Revision:

1.4.0

Quality Check Items:

Rationale is required for all answers of No

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)

N/A

Comments:

ARCHGLBPRM_ONEOVER2PI constant used instead of ONEOVER2PI defined in FDD

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

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

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

EA4#10010

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 :

03/23/17

Lead Peer Reviewer:

Shruthi Raghavan

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:

MotRplCoggCmd_MDD.docx

MDD Revision:

2

Source File Name:

CDD_MotRplCoggCmd_MotCtrl.c

Source File Revision:

5

Source File Name:

CDD_MotRplCoggCmd.c

Source File Revision:

1

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

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:

Avinash James

Review Date :

03/23/17

Lead Peer Reviewer:

Shruthi Raghavan

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_MotRplCoggCmd.c

Source File Revision:

1

Source File Name:

CDD_MotRplCoggCmd_MotCtrl

Source File Revision:

5

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:

Avinash James

Review Date :

03/23/17

Lead Peer Reviewer:

Shruthi Raghavan

Approved by Reviewer(s):

Yes

Other Reviewer(s):

30.4 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
SF107A	28	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	147	I
SF107A	61	CDD_MotRplCoggCmd.c	MotRplCoggCmdInit1	208-221	I
SF107A	27	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	100	I
SF107A	48	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	120,124	I
SF107A	46	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	97	I
SF107A	47	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	165	I
SF107A	44	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	106	I
SF107A	45	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	99	I
SF107A	42	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	105	I
SF107A	43	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	98	I
SF107A	40	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	103	I
SF107A	41	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	104	I
SF107A	39	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	101	I
SF107A	38	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	102	I
SF107A	59	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	145	I
SF107A	33	CDD_MotRplCoggCmd.c	GetMotCoggCmdPrm_Oper	167	I
SF107A	32	CDD_MotRplCoggCmd.c	SetMotCoggCmdPrm_Oper	271	I
SF107A	57	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	150-160	I
SF107A	56	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	137	I
SF107A	51	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	113-116	I
SF107A	50	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	120,124,132	I
SF107A	53	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	150-160	I
SF107A	55	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	150-160	I
SF107A	54	CDD_MotRplCoggCmd_MotCtrl.c	MotRplCoggCmdPer1	150-160	I

31 - Component Implementation

Component Implementation

Component Documentation

31.1 - MotTqCmdSca_IntegrationManual

Integration Manual

For

Motor Torque Command Scale

VERSION: 2.0

DATE: 14-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	Kannappa Chidambaram P R	1.0	01/21/2016
2	Updated as per FDD v 1.2.0	Krishna Anne	2.0	03/14/2016

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1.1 RTE NvM Blocks 10

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

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

Please refer DataDict.m file.

Required Global Data Outputs

Please refer DataDict.m file.

Specific Include Path present

NA

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotTqCmdScaInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
MotTqCmdScaPer1	None	RTE(2 ms)
SetMotTqCmdSca_Oper	None	On event
GetMotTqCmdSca_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

RTE NvM Blocks

Block Name

MotTqScaFac

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None.

Appendix

None.

31.2 - MotTqCmdSca_MDD

Module Design Document

For

MotTqCmdSca

Prepared For:

,

Prepared By:

Krishna Anne,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Sl. No.	Description	Author	Version	Date
1	Initial version	Kannappa Chidambaram P R	1.0	01/21/2016
2	Updated as per FDD v 1.2.0	Krishna Anne	2.0	03/14/2016

Table of Contents

2 MotTqCmdSca & High-Level Description 6

1.2 Scope 5

3.1 Graphical representation of MotTqCmdSca 7

5.1.1 Init: MotTqCmdScaInit1 9

5.1.2 Per: MotTqCmdScaPer1 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2.1.1 Design Rationale 9

5.2.1 SetMotTqCmdSca 9

5.2.1.2 (Processing of function)……… 9

5.5 GLOBAL Function/Macro Definitions 10

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

Introduction

Purpose

MotTqCmdSca & High-Level Description

Please refer FDD

Design details of software module

Graphical representation of MotTqCmdSca

Data Flow Diagram

Please Refer FDD

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Please refer .m file

Software Component Implementation

Sub-Module Functions

Init: MotTqCmdScaInit1

Design Rationale

Please refer FDD

Module Outputs

Please refer FDD

Per: MotTqCmdScaPer1

Design Rationale

Please refer FDD

Store Module Inputs to Local copies

Please refer FDD

(Processing of function)………

Please refer FDD

Store Local copy of outputs into Module Outputs

Please refer FDD

Server Runables

SetMotTqCmdSca

Design Rationale

Please refer FDD

(Processing of function)………

Please refer FDD

Server Runables

GetMotTqCmdSca

Design Rationale

Please refer FDD

(Processing of function)………

Please 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.00
3	Software Naming Conventions.doc	Process 4.02.00
4	Software Design and Coding Standards.doc	Process 4.02.00
5	FDD: SF032A_MotTqCmdSca_Design	See Synergy sub project version

31.3 - MotTqCmdSca_Review

Review_Checklist

Overview

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. SF032A_MotTqCmdSca_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. SF032A_MotTqCmdSca_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#4308

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

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 :

03/14/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

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

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:

Krishna Anne

Review Date :

03/14/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:

MotTqCmdSca.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:

MotTqCmdSca_MDD

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

SF032A_MotTqCmdSca_Design

Revision:

1.2.0

Quality Check Items:

Rationale is required for all answers of No

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:

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

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

N/A

Comments:

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

All code is mapped with FDD (all FDD

Yes

Comments:

subfunctions and/or model blocks identified

with code comments; all code corresponds to

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

Review did not identify violations of other

Yes

Comments:

coding standard rules

Anomaly or Design Work CR created

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 :

03/14/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:

MotTqCmdSca_MDD

MDD Revision:

2

Source File Name:

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

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 :

03/14/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:

MotTqCmdSca.c

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

03/14/16

Lead Peer Reviewer:

Nick Saxton

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. MotTqCmdSca_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. 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:

Krishna Anne

Review Date :

03/14/16

Lead Peer Reviewer:

Nick Saxton

Approved by Reviewer(s):

Yes

Other Reviewer(s):

31.4 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
SF032A	11	MotTqCmdSca.c	GetMotTqCmdSca_Oper	130	I
SF032A	13	MotTqCmdSca.c	SetMotTqCmdSca_Oper	276	I
SF032A	45	MotTqCmdSca.c	SetMotTqCmdSca_Oper	276	I
SF032A	14	MotTqCmdSca.c	SetMotTqCmdSca_Oper	276	I
SF032A	48	MotTqCmdSca.c	MotTqCmdScaInit1	174,176-183,177-183	I
SF032A	47	MotTqCmdSca.c	MotTqCmdScaInit1	172,174-183	I
SF032A	30	MotTqCmdSca.c	GetMotTqCmdSca_Oper	130	I
SF032A	51	MotTqCmdSca.c	GetMotTqCmdSca_Oper	130	I
SF032A	50	MotTqCmdSca.c	GetMotTqCmdSca_Oper	130	I
SF032A	34	MotTqCmdSca.c	MotTqCmdScaPer1	224-229	I
SF032A	36	MotTqCmdSca.c	MotTqCmdScaPer1	231	I

32 - Component Implementation

Component Implementation

Component Documentation

32.1 - MotTqTranlDampg_IntegrationManual

Integration Manual

For

Transistional Damping (SF-50A)

VERSION: 1.0

DATE: 12-AUG-2015

Prepared By:

Krishna Kanth 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	Krishna Kanth Anne	1.0	08/12/2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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

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

Runnable	Scheduling Requirements	Trigger
MotTqTranlDampgPer1	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

32.2 - MotTqTranlDampg_MDD

Module Design Document

For

Transistional Damping (SF-50A)

August 12, 2015

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Krishna Kanth Anne,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Krishna Kanth Anne	EA4 01.00.01	12-Aug-2015

Table of Contents

2 MotTqTranlDampg & High-Level Description 6

1.2 Scope 5

3.1 Graphical representation of MotTqTranlDampg 7

5.1.1 Init: MotTqTranlDampgInit1 10

5.1.1.1 Design Rationale 10

5.1.1.2 Module Outputs 10

5.1.2 Per: MotTqTranlDampgPer1 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.2 Server Runables 10

5.3 Interrupt Functions 10

5.4.1 Local Function #1 10

5.4.1.1 Design Rationale 11

5.4.1.2 Processing 11

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

5.5.1 GLOBAL Function #1 11

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Introduction

Purpose

MDD for Motor Torque Transistional Damping.

Scope

MotTqTranlDampg & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation of MotTqTranlDampg

Data Flow Diagram

Please refer FDD.

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Please refer .m file

Software Component Implementation

Sub-Module Functions

Init: MotTqTranlDampgInit1

Design Rationale

None

Module Outputs

None

Per: MotTqTranlDampgPer1

Design Rationale

None

Store Module Inputs to Local copies

Please refer FDD

(Processing of function)………

Please refer FDD

Store Local copy of outputs into Module Outputs

Please refer FDD

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	SwOpCtrlPart1	Type	Min	Max
Arguments Passed	TranlDampgTiElpsd_MilliSec_T_f32	float32	0.0	1000.0
Arguments Passed	AbslMotVelCrf_MotRadPerSec_T_f32	float32	0.0	1350.0
Return Value	MotTqTranlDampgCmpl_Cnt_T_lgc	boolean	FALSE	TRUE

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “SwOutputCntrl” block of the Simulink model of the design.

Local Function #2

Function Name	SwOpCtrlPart2	Type	Min	Max
Arguments Passed	DiagcStsCtrldShtDwnFltPrsnt_Cnt_T_lgc	boolean	FALSE	TRUE
Arguments Passed	CtrlDampTrq_MotNwtMtr_T_f32	float32	-3.0	3.0
	SysSt_Cnt_T_enum	SysSt1	0	3
	MotTqCmdCrf_MotNwtMtr_T_f32	float32	-8.8	8.8
	MotTqTranlDampgCmpl_Cnt_T_lgc	boolean	FALSE	TRUE
Return Value	MotTqCmdCrfDampd_MotNwtMtr_T_f32	float32	-11.8	11.8

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “SwOutputCntrl” block of the Simulink model of the design.

GLOBAL Function/Macro Definitions

None

GLOBAL Function #1

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

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.0
5	FDD : SF050A_MotTqTranlDampg_Design (V 1.1.0)	See Synergy sub project version

32.3 - MotTqTranlDampg_Review

Overview

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. SF050A_MotTqTranlDampg_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. SF050A_MotTqTranlDampg_Imp_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#11228

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:

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

05/02/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

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)

No changes

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

No changes

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

No changes

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

No changes

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

removed

No changes

All sender/receiver port read/writes using direct

N/A

Comments:

read/writes(List justification if not)

No changes

Runnable calling frequencies match FDD

N/A

Comments:

No changes

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

No changes

Component is correct component type

Yes

Comments:

No changes

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 :

05/02/17

Component Type :

Application

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Other Reviewer(s):

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

MotTqTranlDampg.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:

MotTqTranlDampg_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF050A_MotTqTranlDampg_Design

Revision:

1.3.0

Quality Check Items:

Rationale is required for all answers of No

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

No Req Tags

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

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

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:

MCC coverage as per SIL reports is 94% and Boundary value coverage in 44%; These are less than the coverages observed in PIL reports of previous versions. Reason being the test vectors of MIL testing, an ICR is required for re-running the MIL and subsequent SIL tests.

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 :

05/02/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:

MotTqTranlDampg.c

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

05/02/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

33 - Component Implementation

Component Implementation

Component Documentation

33.1 - MotVel_Integration Manual

Integration Manual

For

‘MotVel’

VERSION: 1.0

DATE: 12-April-2016

Prepared By:

Software Group

Nexteer Automotive,

Saginaw, MI, USA

Revision History

: ARM Cortex R4 Memory Usage
Sl. No.	Description	Author	Version	Date
1	Initial version	Rijvi Ahmed	1.0	12-April-2016

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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

Dependencies

SWCs

Module	Required Feature
None

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

MotVelPer1

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

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotVelInit1	None	RTE/Init

Runnable	Scheduling Requirements	Trigger
MotVelPer1	None	Motor Control ISR
MotVelPer2	None	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
<Memmap usuage info>

Non RTE NvM Blocks

Block Name
None

RTE NvM Blocks

Block Name
none

Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None

Appendix

None

33.2 - MotVel_MDD

Module Design Document

For

‘MotVel’

VERSION: 2.0

DATE: 25-Jul-2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Shawn Penning

Saginaw, MI

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	12-April-2016
2	Updated per design rev. 2.0.0	TATA	2.0	18-Nov-2016
3	Updated per design rev. 2.1.0	Shawn Penning	3.0	25-Jul-2017

Table of Contents

3 MotVel & High-Level Description 7

4.1 Graphical representation OF MotVel 8

7.1.1 Initialization Functions 11

7.1.2 PERIODIC FUNCTIONS 11

7.1.2.1 INIT: MotVelPER1 11

7.1.2.1.1 Design Rationale 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 PERIODIC FUNCTIONS 11

7.1.3.1 INIT: MotVelPER2 11

7.1.3.1.1 Design Rationale 11

7.1.3.2 Design Rationale 11

7.1.3.3 Store Module Inputs to Local copies 11

7.1.3.4 (Processing of function)……… 11

7.1.3.5 Store Local copy of outputs into Module Outputs 11

7.1.4 Interrupt Functions 12

Server runnables 12

7.1.4.1.1 Store Local copy of outputs into Module Outputs 12

7.1.4.2 Local Function/Macro Definitions 12

7.1.5 GLObAL Function/Macro Definitions 12

7.1.6 Tranisition FUNCTIONS 12

8 Known Limitations With Design 13

9 UNIT TEST CONSIDERATION 14

10 Appendix 15

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	MDD Guidelines	Process 04.02.01
2	Software Naming Conventions	Process 04.02.01
3	Software Design and Coding standards	Process 04.02.01
4	FDD : SF40A_MotVel_Design	See Synergy sub project version

MotVel & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation OF MotVel

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

None

N/A

Variable definition for enumerated types

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

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value
Refer the m files

6.1.1.2 Global

Constant Name
N/A

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
None	N/A	N/A	N/A

Software Module Implementation

Sub-Module Functions

Initialization Functions

None

PERIODIC FUNCTIONS

INIT: MotVelPER1

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

PERIODIC FUNCTIONS

INIT: MotVelPER2

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

Interrupt Functions

None

Server runnables

None

Store Local copy of outputs into Module Outputs

None

Local Function/Macro Definitions

None

GLObAL Function/Macro Definitions

None

Tranisition FUNCTIONS

None

Known Limitations With Design

Per-Instance Memory variables in Design 2.1, MotAgBufIdxPrev and MotAgBufIdxPrim, are set with range of 0 to 255, but are index variables for an array of only 8 elements. Design to be corrected in the next version as follows: the Max Value for both PIM’s to be 7 instead of 255 (range 0..7 instead of 0..255).

UNIT TEST CONSIDERATION

Per-Instance Memory variables in Design 2.1, MotAgBufIdxPrev and MotAgBufIdxPrim, are set with range of 0 to 255, but are index variables for an array of only 8 elements. Design to be corrected in the next version as follows: the Max Value for both PIM’s to be 7 instead of 255 (range 0..7 instead of 0..255).

Appendix

None

33.3 - MotVel_Peer Review Checklist

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. SF040A_MotVel_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. SF040A_MotVel_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. Shawn Penning

Work CR ID:

EA4#12461

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/28/17

Lead Peer Reviewer:

Brendon Binder

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:

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

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/28/17

Component Type :

CDD

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

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_MotVel.c

Source File Revision:

4

Header File Name:

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

MotVel_MDD.doc

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

SF040A_MotVel_Design

Revision:

2.1.0

Quality Check Items:

Rationale is required for all answers of No

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

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 :

07/28/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

MotVel_MDD.doc

MDD Revision:

3.0

Source File Name:

CDD_MotVel.c

Source File Revision:

4

Source File Name:

CDD_MotVel_MotCtrl.c

Source File Revision:

2

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:

See comment below

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:

Added range issue

General Notes / Comments:

Range issue to be corrected has been noted in the Design and Unit Test considerations.

Verified that the design will be changed in ver 2.2 in email from Krishna Namburi dated 7/31/17

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/28/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (PolySpace Review)

Source File Name:

CDD_MotVel.c

Source File Revision:

4

Source File Name:

CDD_MotVel_MotCtrl.c

Source File Revision:

2

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Stubs.c and Stubs.h were modified mannually to eliminate PolySpace warnings. A recommendation for changes to TL109A have been placed on the TL109A change spreadsheet, but the current version does not support this component due to the unique input arrays, MotAgBuf and MotAgTiBuf.

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/28/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

34 - Component Implementation

Component Implementation

Component Documentation

34.1 - PosnTrakgServo_IntegrationManual

Integration Manual

For

Position Tracking Servo

VERSION: 1.0

DATE: 20-Jan-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	Matthew Leser	1.0	20-Jan-2017

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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

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

Runnable	Scheduling Requirements	Trigger
PosnTrakgServoPer1	None	RTE(2 ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None

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

34.2 - PosnTrakgServo_MDD

Module Design Document

For

Jan 20, 2017

Prepared For:

Software Engineering

,

Saginaw, MI, USA

Prepared By:

Matthew Leser

,

Change History

Description	Author	Version	Date
Initial Version	Matthew Leser	1.0	20-Jan-2017

Table of Contents

2 PosnTrakgServo & High-Level Description 6

3.1 Graphical representation of PosnTrakgServo 7

5.1.1 Init: PosnTrakgServoInit1 9

5.1.2 Per: PosnTrakgServoPer1 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.4 Module Internal (Local) Functions 9

5.4.1 Local Function #1 9

5.4.1.1 Design Rationale 10

5.4.1.2 Processing 10

5.5 GLOBAL Function/Macro Definitions 10

Summary Sheet
Synergy Project
Source Code
PolySpace

Introduction

Purpose

MDD for Position Tracking Servo.

PosnTrakgServo & High-Level Description

Please refer FDD

Design details of software module

Graphical representation of PosnTrakgServo

Data Flow Diagram

Please refer FDD

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value

Software Component Implementation

Sub-Module Functions

Init: PosnTrakgServoInit1

Design Rationale

None

Module Outputs

None

Per: PosnTrakgServoPer1

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Please refer FDD

Store Local copy of outputs into Module Outputs

Please refer FDD

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	SVReset	Type	Min	Max
Arguments Passed	PosnServoEna_Cnt_T_lgc	Boolean	FALSE	TRUE
	SVResetInp_HwNwtMtr_T_f32	Float32
Return Value	SVResetOup_Uls_T_f32	Float32

Design Rationale

NA

Processing

Please refer SVReset block of the 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.00
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD: SF020B_PosnTrakgServo_Design	See Synergy sub project version

34.3 - PosnTrakgServo_Review

Overview

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. SF020B_PosnTrakgServo_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#10235

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:

MDD

Source Code

PolySpace

Integration Manual

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/31/17

Lead Peer Reviewer:

Shruthi R

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:

PosnTrakgServo.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:

PosnTrakgServo_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF020B_PosnTrakgServo_Design

Revision:

1.1.0

Quality Check Items:

Rationale is required for all answers of No

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:

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

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

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:

Matthew Leser

Review Date :

03/31/17

Lead Peer Reviewer:

Shruthi R

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:

PosnTrakgServo.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 TL_100A_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

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/31/17

Lead Peer Reviewer:

Shruthi R

Approved by Reviewer(s):

Yes

Other Reviewer(s):

35 - Component Implementation

Component Implementation

Component Documentation

35.1 - PwrLimr_IntegrationManual

Integration Manual

For

PwrLimr

VERSION: 1.0

DATE: 14-AUG-2015

Prepared By:

Nick Saxton,

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

Description	Author	Version	Date
Initial version	Nick Saxton	1.0	14-Aug-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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	EA4 Software Naming Conventions.doc	01.00.00
2	Software Design and Coding Standards.doc	2.1
3	SF019B_PwrLimr_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
PwrLimrInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
PwrLimrPer1	None	RTE 2ms
PwrLimrPer2	None	RTE 10ms

.

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

35.2 - PwrLimr_MDD

Module Design Document

For

PwrLimr

19-Oct-2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Brendon Binder,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Nick Saxton	1.0	14-Aug-2015
As per FDD v 2.0.1	Krishna Anne	2.0	09-Nov-2016
Implemented FDD v 4.0.0	Brendon Binder	3.0	19-Oct-2017

Table of Contents

1 PwrLimr High-Level Description 5

2 Design details of software module 6

2.1 Graphical representation of PwrLimr 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

4 Software Component Implementation 8

4.1 Sub-Module Functions 8

4.1.1 Init: PwrLimrInit1 8

4.1.1.1 Design Rationale 8

4.1.1.2 Module Outputs 8

4.1.2 Per: PwrLimrPer1 8

4.1.2.1 Design Rationale 8

4.1.2.2 Store Module Inputs to Local copies 8

4.1.2.3 (Processing of function)……… 8

4.1.2.4 Store Local copy of outputs into Module Outputs 8

4.1.3 Per: PwrLimrPer2 8

4.1.3.1 Design Rationale 8

4.1.3.2 Store Module Inputs to Local copies 8

4.1.3.3 (Processing of function)……… 8

4.1.3.4 Store Local copy of outputs into Module Outputs 8

4.2 Server Runnables 9

4.3 Interrupt Functions 9

4.4 Module Internal (Local) Functions 9

4.4.1 AssiLimCdn 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 14

PwrLimr High-Level Description

Refer FDD

Design details of software module

Graphical representation of PwrLimr

Data Flow Diagram

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
BIT1MASK_ULS_U08	1	Uls	2U
Refer DataDict.m

Software Component Implementation

Sub-Module Functions

Init: PwrLimrInit1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: PwrLimrPer1

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

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

AssiLimCdn

Function Name	AssiLimCdn	Type	Min	Max
Arguments Passed	FildTqLim_Uls_T_f32	float32	0.0F	1.0F
	BrdgVltg_Volt_T_f32	float32	6.0F	26.5F
Return Value	None	N/A	N/A	N/A

Design Rationale

See “Asst_Lmt_Condition_Determination” block in the Simulink model of the design.

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.01.00
4	Software Design and Coding Standards.doc	2.1
5	FDD – SF019B Power Limiter	See Synergy subproject version

35.3 - PwrLimr_PeerReviewChecklist

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. SF019B_PwrLimr_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. SF019B_PwrLimr_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#21038

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

N/A

Source Code

N/A

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

The baseline is made from a PSR code for the anomaly fix for EA4#17673. Due to timing constraints and

the changes being small, its being baselined without the formal review process - Approved deviation by Lonnie Newton

The design sub project is also deleted to not have a mismatch with the model as design is not yet ready

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.

36 - Component Implementation

Component Implementation

Component Documentation

36.1 - Rtn_Integration Manual

Integration Manual

For

Return

VERSION: 2.0

DATE: 29-Nov-2016

Prepared For:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

TATA ELXSI

CHENNAI, INDIA

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	30-Jun-2015
2	Updated per design rev. 2.0.0	TATA	2.0	29-Nov-2016

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

5.3 file Specific Include Path present 8

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

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 4.01.00
<2>	<Software Naming Conventions>	Process 4.01.00
<3>	<Coding standards>	Process 4.01.00
<4>	<FDD SF002A_Rtn_Design >	See Synergy Subproject version
	<Add if more available>

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

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

file Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
RtnInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
RtnPer1	None	RTE(2ms)

.

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

36.2 - Rtn_Module Design Document

Module Design Document

For

Return

Nov 29, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

TATA ELXSI

CHENNAI, INDIA

Change History

Description	Author	Version	Date
Initial Version	SB	1	30-Jun-2015
Updated per design rev. 2.0.0	TATA	2.0	29-Nov-2016

Table of Contents

1 Introduction 3

1.1 Purpose 3

2 Rtn High-Level Description 4

3 Design details of software module 5

3.1 Graphical representation of Rtn 5

3.2 Data Flow Diagram 5

3.2.1 Component level DFD 5

3.2.2 Function level DFD 5

4 Constant Data Dictionary 6

4.1 Program (fixed) Constants 6

4.1.1 Embedded Constants 6

5 Software Component Implementation 7

5.1.1 Sub-Module Functions 7

5.1.2 Interrupt Service Routines 7

5.1.3 Server Runnable Functions 7

5.1.4 Module Internal (Local) Functions 7

5.1.5 Transition Functions 7

6 Known Limitations with Design 8

7 UNIT TEST CONSIDERATION 9

Appendix A Abbreviations and Acronyms 10

Appendix B Glossary 11

Appendix C References 12

Introduction

Purpose

MDD for Return

Rtn High-Level Description

Refer to FDD

Design details of software module

Graphical representation of Rtn

$C:\Component\SF002A_Rtn_Impl_1.4.2\snapp.JPG$

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

None

Software Component Implementation

Sub-Module Functions

Initialization sub-module RtnInit1

Periodic sub-module RtnPer1

Design Rationale - Fault Injection client call is conditional compiled based on “FLTINJENA” build constant.

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

None

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 – SF002A_Rtn_Design	See Synergy Sub project version

36.3 - Rtn_PeerReview

Overview

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. SF002A_Rtn_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. SF002A_Rtn_Impl_2.2.1

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. Krzysztof Byrski

Work CR ID:

EA4#12636

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:

MDD

Yes

Source Code

Yes

PolySpace

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:

SF002A_Rtn_Design_2.2.0

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:

Krzysztof Byrski

Review Date :

06/28/2017

Lead Peer Reviewer:

Mateusz Bartocha

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

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

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

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

Yes

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:

Krzysztof Byrski

Review Date :

06/28/2017

Component Type :

Application

Lead Peer Reviewer:

Mateusz Bartocha

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:

Rtn.c

Source File Revision:

8

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:

Rtn_Module Design Document.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

SF002A_Rtn_Design

Revision:

2.2.0

Quality Check Items:

Rationale is required for all answers of No

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:

All other includes are actually needed. (System includes

N/A

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:

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:

Krzysztof Byrski

Review Date :

06/28/2017

Lead Peer Reviewer:

Mateusz Bartocha

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:

Rtn.c

Source File Revision:

8

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

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 TL108A_PolyspaceSuprt_2.0.1

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

Unnecessary justifications have been removed

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:

Krzysztof Byrski

Review Date :

06/28/2017

Lead Peer Reviewer:

Mateusz Bartocha

Approved by Reviewer(s):

Yes

Other Reviewer(s):

37 - Component Implementation

Component Implementation

Component Documentation

37.1 - RtnPahFwl_IntegrationManual

Integration Manual

For

Return Path Firewall

VERSION: 1.0

DATE: 3-Feb-2016

Prepared By:

Akhil Krishna N D(Tata Elxsi),

Trivandrum, INDIA

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Akhil Krishna N D	1.0	03-Feb-2016

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 : SF036A_RtnPahFwl_Design	See Synergy sub project version
2	Software Naming Conventions	1.0
3	Software Design and Coding Standards	2.0

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

Please refer DataDict.m file.

Required Global Data Outputs

Please refer DataDict.m file.

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
RtnPahFwlInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
RtnPahFwlPer1	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.

37.2 - RtnPahFwl_MDD

Module Design Document

For

RtnPahFwl

February 3, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Akhil Krishna N D (Tata Elxsi),

Trivandrum, INDIA

Change History

Description	Author	Version	Date
Initial Version	Akhil Krishna N D	EA4 01.00.01	3-Feb-2015

Table of Contents

2 RtnPahFwl & High-Level Description 5

3.1 Graphical representation of RtnPahFwl 6

5.1.1 Init: RtnPahFwlInit1 8

5.1.2 Per: RtnPahFwlPer1 8

5.1.1.2 Module Outputs 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

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Introduction

Purpose

MDD for Return Path Firewall.

RtnPahFwl & High-Level Description

Please refer FDD

Design details of software module

Graphical representation of RtnPahFwl

Data Flow Diagram

Please refer FDD

Component level DFD

Please refer FDD

Function level DFD

Please refer FDD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
NODEBSTEP_CNT_U16	1	Cnt	65535
Please refer .m file for the rest

Software Component Implementation

Sub-Module Functions

Init: RtnPahFwlInit1

Design Rationale

None

Module Outputs

None

Per: RtnPahFwlPer1

Design Rationale

None

Store Module Inputs to Local copies

None

(Processing of function)………

Please refer FDD

Store Local copy of outputs into Module Outputs

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

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.0
5	FDD: SF036A_RtnPahFwl_Design	See Synergy sub project version

37.3 - RtnPahFwl_Review

Overview

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. SF036A_RtnPahFwl_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. SF036A_RtnPahFwl_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. Krishna Anne

Work CR ID:

EA4#3990

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:

MDD

Yes

Source Code

Yes

PolySpace

Integration Manual

Yes

Davinci Files

Comments:

Only change is the dimensions of RtnPahFwlUpprBndTblY cal. Contract files are updated.
Source code is not changed (version incremented by updating appropriate 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 :

02/26/16

Lead Peer Reviewer:

Sankardu V

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

No changes made w.r.t this in the current change

Sender/Receiver port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

No changes made w.r.t this in the current change

Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

No changes made w.r.t this in the current change

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

N/A

Comments:

read/writes(List justification if not)

No changes made w.r.t this in the current change

Runnable calling frequencies match FDD

N/A

Comments:

No changes made w.r.t this in the current change

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

No changes made w.r.t this in the current change

Component is correct component type

Yes

Comments:

No changes made w.r.t this in the current change

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 :

02/26/16

Component Type :

Application

Lead Peer Reviewer:

Sankardu V

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:

RtnPahFwl.c

Source File Revision:

2

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.

MDD Name:

RtnPahFwl_MDD

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF036A_RtnPahFwl_Design

Revision:

1.0.2

Quality Check Items:

Rationale is required for all answers of No

Summary Sheet
Synergy Project
Source Code
PolySpace

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:

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

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 :

02/26/16

Lead Peer Reviewer:

Sankardu V

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:

RtnPahFwl.c

Source File Revision:

2

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 :

02/26/16

Lead Peer Reviewer:

Sankardu V

Approved by Reviewer(s):

Yes

Other Reviewer(s):

38 - Component Implementation

Component Implementation

Component Documentation

38.1 - StabyCmp_DesignReview

Overview

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. SF029A_StabyCmp_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. SF029A_StabyCmp_Impl_1.3.0

Change Owner:

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

Work CR ID:

EA4#10102

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 for changes for fixing anomaly EA4#9985 only

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 :

02/24/17

Lead Peer Reviewer:

Avinash James

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:

StabyCmp.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:

StabyCmp_MDD.docx

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

SF029A_StabyCmp_Design

Revision:

1.3.0

Quality Check Items:

Rationale is required for all answers of No

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:

See MDD design Rationale for Notch filter PIM

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

FilNotchInit' implementation is based on EA3.

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

FDD change to correct filter implementation not done (time crunch for implementation before build date)

Anomaly or Design Work CR created

No

Comments: List Anomaly or CR numbers

for any FDD corrections needed

Systems group have been contacted for notch filter model

to be created to address the deviations noted in the MDD

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 :

02/24/17

Lead Peer Reviewer:

Avinash James

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:

StabyCmp.c

Source File Revision:

4

Source File Name:

N/A

Source File Revision:

N/A

Source File Name:

N/A

Source File Revision:

N/A

EA4 Static Analysis Compliance Guideline version:

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

StaticPathCount=1, CyclomaticComplexity=1

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 :

02/24/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

38.2 - StabyCmp_IntegrationManual

Integration Manual

For

StabyCmp

VERSION: 1.0

DATE: 21-July-2015

Prepared By:

Sankardu Varadapureddi,

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	21-July-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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
v	FDD – SF029A_StabyCmp_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
StabyCmpInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
StabyCmpPer1	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

38.3 - StabyCmp_MDD

Module Design Document

For

StabyCmp

Jan 27, 2017

Prepared By:

Shruthi Raghavan,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Sankardu Varadapureddi	1.0	21-July-2015
Updated for FDD version 1.1.0	Sankardu Varadapureddi	2.0	11-Mar-2016
Updated to FDD version 1.3.0	Shruthi Raghavan	3.0	27-Jan-2017

Table of Contents

2 StabyCmp High-Level Description 5

3.1 Graphical representation of ‘StabyCmp’ 6

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.2 Local Function #1 8

5.3 Description 8

5.4 Local Function #2 9

5.5 Description 9

5.5.1 Transition Functions 9

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Introduction

Purpose

Module design document for Stability Compensation.

StabyCmp High-Level Description

Refer FDD

Design details of software module

Graphical representation of ‘StabyCmp’

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
None

Software Component Implementation

Sub-Module Functions

Initialization sub-module {StabyCmpInit1}

Design Rational:

FDD details are not complete for notch filter initialization. Upon discussion with FDD owner, implemented in line with EA3 implementation.

Periodic sub-module {StabyCmpPer1}

Refer FDD for details

Design Rational:
In design version 1.3.0, .m file has some additional PIMs for notch filters, which are not required in the notch filter implementation. Notch filter implementation in SW based on design 1.0.0 .m file PIMs is not changed.
New FDD model was requested but this wasn’t done on time and due to time crunch the difference between implementation and the model still exists.

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	FilNotchInit	Type	Min	Max
Arguments Passed	Inp	float32	See unit test consideration
	FilNotchStRecPtr	FilNotchStRec1
	FilNotchGainRecPtr	FilNotchGainRec1
Return Value	None

Description

Notch filter initialization function implemented based on EA3 design.

Local Function #2

Function Name	FilNotchFullUpdOutp_f32	Type	Min	Max
Arguments Passed	Inp	float32	See unit test consideration
	FilNotchStRecPtr	FilNotchStRec1
	FilNotchGainRecPtr	FilNotchGainRec1
Return Value	FilOut	float32

Description

Notch filter output calculation. Implemented based on ‘Compensator1’ block functionality. Compensator2, Compensator3 and Compensator4 also have the same functionality.

Transition Functions

None

Known Limitations with Design

Design has 8 PIMs to represent notch filters and a model block for notch filter has not been designed. This hasn’t been done yet in this revision due to the need to baseline on time for builds. No anomaly has been written but the Systems group was notified.

UNIT TEST CONSIDERATION

Since the notch filter implementation used in this module is dynamic in nature, absolute ranges are difficult to determine without pre-defined knowledge on the combination of coefficient values (A1, A2, B0, B1, B2). Because of this, the systems group ran simulations on 10 different combinations of coefficients (2 with defined default calibrations, 8 considered extreme cases of notch filters) and logged the ranges of the filter state variables and outputs during a frequency sweep. The ranges given throughout this module were taken as the worst case results of all of the given test cases.

To provide useful cases for unit testing, the boundary checks tested during unit testing should be altered to test the state variable minimum and maximum for each of the 10 test cases with the given coefficients set to the values given in that test case. In the case where the default values of the coefficients are used in a vector, the unit tester should not test the corresponding state variables with values over the range defined for that set of coefficients. See attached simulation results.

(Note: this section is copied from EA3 Stability Compensation documentation)

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	FDD - SF029A_StabyCmp_Design	See Synergy sub project version

39 - Component Implementation

Component Implementation

Component Documentation

39.1 - StOutpCtrl Review

Overview

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. SF005A_StOutpCtrl_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. SF005A_StOutpCtrl_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. Shawn Penning

Work CR ID:

EA4#11057

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

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 :

05/10/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

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

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

Yes

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:

Shawn Penning

Review Date :

05/10/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:

StOutpCtrl.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:

StOutpCtrl_MDD.doc

Revision:

3

FDD/SCIR/DSR/FDR/CM Name:

SF005A_StOutpCtrl_Design

Revision:

1.4.0

Quality Check Items:

Rationale is required for all answers of No

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

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

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 :

05/10/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:

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

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 :

05/10/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brendon Binder

Matt Leser

Brionna Spencer

39.2 - StOutpCtrl_IntegrationManual

Integration Manual

For

StOutpCtrl

VERSION: 1.0

DATE: 02-June-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	Akilan Rathakrishnan	1.0	02-June-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 - <FDD SF005A_StOutpCtrl_Design>	Refer 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

< 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
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 SF005A_StOutpCtrl_DataDict.m file

Required Global Data Outputs

Refer SF005A_StOutpCtrl_DataDict.m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
StOutpCtrlInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
StOutpCtrlPer1	None	RTE 2ms Task

.

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

<This section is for appendix>

39.3 - StOutpCtrl_MDD

Module Design Document

For

StOutpCtrl

VERSION: 3

DATE: 5-Dec-2016

Prepared By:

Matthew Leser

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	Akilan Rathakrishnan	1.0	02-June-2015
2	Implementation of input name change	Basavaraja Ganeshappa	2.0	30-June-2016
3	Updated to fix Anomaly EA4#7767	Matthew Leser	3.0	05-Dec-2016

Table of Contents

3 StOutpCtrl - High-Level Description 7

4.1 Graphical representation of StOutpCtrl 8

7.1.1 Initialization Functions 11

7.1.1.1 INIT: StOutpCtrlInit1 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: StOutpCtrlPer1 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.2 Interrupt Functions 11

7.3 Serial Communication Functions 11

7.4 Local Function/Macro Definitions 12

7.4.1 Local Function #1: RateLimit 12

7.4.1.1 Description 12

7.4.1.2 Design Rationale 12

7.4.2 Local Function #1: RateSource 12

7.4.2.1 Description 12

7.4.2.2 Design Rationale 12

7.5 GLObAL Function/Macro Definitions 12

7.5.1 GLObAL Function #1 12

7.5.1.1 Description 12

7.6 TRANSIENT FUNCTIONS 13

8 Known Limitations With Design 14

9 UNIT TEST CONSIDERATION 15

10 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 4.02.01
<2>	<Software Naming Conventions>	Process 4.02.01
<3>	<Coding standards>	2.1
<4>	<FDD SF005A_StOutpCtrl_Design>	See Synergy Subproject version
	<Add if more available>

StOutpCtrl - High-Level Description

Refer FDD

Design details of software module

Graphical representation of StOutpCtrl

Data Flow Diagram

N/A

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

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

N/A

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 Constant name qualified in [2]>	<Refer MDD guidelines [1]>	<Refer MDD guidelines [1]>	<Refer MDD guidelines [1]>

Software Module Implementation

Sub-Module Functions

None

Initialization Functions

INIT: StOutpCtrlInit1

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

PERIODIC FUNCTIONS

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

Per: StOutpCtrlPer1

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

Interrupt Functions

None

Serial Communication Functions

None

Local Function/Macro Definitions

Local Function #1: RateLimit

Function Name	RateLimit	Type	Min	Max
Arguments Passed	SysOperRampRate_UlspS_T_f32	float32	0.1	500.0
	LoaRateLim_UlspS_T_f32	float32	0.1	500.0
	VehStrtStopRampRate_UlspS_T_f32	float32	0.1	500.0
Return Value	SelRampRate_UlspS_T_f32	float32	0.1	500.0

Description

Implements "Rate Limit" model block in FDD -- selects ramp rate from input rate limits.

Design Rationale

FDD does not show a default case on the switch/case block in this function because none is required – all possible values of the switch variable (which is internal to this component) are covered by the cases shown. However a default clause is required by MISRA Rule 15.3. Therefore the default label was placed with the final case label in the code; this is functionally equivalent to the FDD and satisfies the MISRA rule.

Local Function #2: RateSource

Function Name	RateSource	Type	Min	Max
Arguments Passed	SysOperMotTqCmdSca_Uls_T_f32	float32	0.0	1.0
	LoaSca_Uls_T_f32	float32	0.0	1.0
	VehStrtStopMotTqCmdSca_Uls_T_f32	float32	0.0	1.0
	SelectedState_Cnt_T_u08	uint8	1	3
Return Value	SelectedTqCmdSca_Uls_T_f32	float32	0.0	1.0

Description

Implements "Rate Source" model block in FDD -- selects scale factor from input rate scales.

Design Rationale

FDD does not show a default case on the switch/case block in this function because none is required – all possible values of the switch variable (which is internal to this component) are covered by the cases shown. However a default clause is required by MISRA Rule 15.3. Therefore the default label was placed with the final case label in the code; this is functionally equivalent to the FDD and satisfies the MISRA rule.

GLObAL Function/Macro Definitions

GLObAL Function #1

Function Name	(Exact name used)	Type	Min	Max
Arguments Passed	None	<Refer MDD guidelines[1]>	<Refer MDD guidelines[1]>	<Refer MDD guidelines[1]>

Return Value	N/A

Description

N/A

TRANSIENT FUNCTIONS

None

Known Limitations With Design

None

UNIT TEST CONSIDERATION

None

Appendix

None

40 - Component Implementation

Component Implementation

Component Documentation

40.1 - SysFricLrng_IntegrationManual

Integration Manual

For

SysFricLrng

VERSION: 5.0

DATE: 04-Oct-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	Basavaraja Ganeshappa	1.0	30-Mar-2016
2	Updated to design version 2.2.0	TATA	2.0	05-Dec-16
3	Updated to design version 2.4.0	KK	3.0	28-Feb-17
4	Remove notes for Integrator Settings	KK	4.0	28-Mar-17
5	Added new Non Rte Server Runnable	ML	5.0	04-Oct-17

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

2 SysFricLrng High-Level Description 7

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
FDD	Functional Design Document
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 Guideline	Process 4.02.01
2	EA4 Software Naming Conventions	Process 4.02.01
3	Software Design and Coding Standards	Process 4.02.01
4	FDD: SF007A_SysFricLrng_Design	See Synergy sub project version

Dependencies

SWCs

Module	Required Feature
None

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

FricLrngShtDwn

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 SF007A_SysFricLrng_DataDict.m

Required Global Data Outputs

Refer SF007A_SysFricLrng_DataDict.m

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
StOutpCtrlInit1	None	RTE – Init

Runnable	Scheduling Requirements	Trigger
StOutpCtrlPer1	None	RTE – 10ms

Server Runnable	Scheduling Requirements	Trigger
ClrFricLrngOperMod	None	On server invocation call
GetFricLrngData	None	On server invocation call
GetFricOffsOutpDi	None	On server invocation call
InitFricLrngTbl	None	On server invocation call
SetFricLrngData	None	On server invocation call
SetFricOffsOutpDi	None	On server invocation call
GetFricData	None	On server invocation call
SetFricData	None	On server invocation call
FricLrngShtDwn	Non Rte Server Runnable. This should be called before the Nvm WriteAll and Shutdown.	On server invocation call

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

Refer Data Dict

Compiler Settings

Preprocessor MACRO

FLTINJENA is used for coditionaly injecting fault

Optimization Settings

None

Appendix

None

40.2 - SysFricLrng_MDD

Module Design Document

For

SysFricLrng

Oct 04, 2017

Prepared By:

Matthew Leser

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	Basavaraja Ganeshappa	1.0	24^th Mar 2016
Re base lined by pulling 1.3.1	Basavaraja Ganeshappa	2.0	25^th Jul 2016
Implementation of SF007A v2.0.0 & v2.1.0	Krishna Anne	3.0	3^rd Oct 2016
Updated to design version 2.2.0	TATA	4.0	05-Dec-16
Updated to design version 2.4.0	KK	5.0	28-Feb-17
Updated Diagram and added Unit Test Consideration	ML	6.0	04-Oct-17

Table of Contents

1 Introduction 6

1.1 Purpose 6

3 Design details of software module 8

3.1 Graphical representation of SysFricLrng 8

3.2 Data Flow Diagram 9

3.2.1 Component level DFD 9

3.2.2 Function level DFD 9

4 Constant Data Dictionary 10

4.1 Program (fixed) Constants 10

4.1.1 Embedded Constants 10

5 Software Component Implementation 11

5.1 Sub-Module Functions 11

5.1.1 Init: SysFricLrngInit1 11

5.1.1.1 Design Rationale 11

5.1.1.2 Module Outputs 11

5.1.2 Per: SysFricLrngPer1 11

5.1.2.1 Design Rationale 11

5.1.2.2 Store Module Inputs to Local copies 11

5.1.2.3 (Processing of function)……… 11

5.1.2.4 Store Local copy of outputs into Module Outputs 11

5.2 Server Runnables 11

5.2.1 Server Runnable Name 11

5.2.1.1 Design Rationale 11

5.2.1.2 (Processing of function)……… 11

5.3 Server Runnables 12

5.3.1 Server Runnable Name 12

5.3.1.1 Design Rationale 12

5.3.1.2 (Processing of function)……… 12

5.3.2 Server Runnable Name 12

5.3.2.1 Design Rationale 12

5.3.2.2 (Processing of function)……… 12

5.3.3 Server Runnable Name 12

5.3.3.1 Design Rationale 12

5.3.3.2 (Processing of function)……… 12

5.3.4 Server Runnable Name 12

5.3.4.1 Design Rationale 12

5.3.4.2 (Processing of function)……… 12

5.3.5 Server Runnable Name 13

5.3.5.1 Design Rationale 13

5.3.5.2 (Processing of function)……… 13

5.3.6 Server Runnable Name 13

5.3.6.2 (Processing of function)……… 13

5.3.7 Server Runnable Name 13

5.3.7.2 (Processing of function)……… 13

5.4 Interrupt Functions 13

5.4.1 Interrupt Function Name 13

5.4.1.1 Design Rationale 13

5.4.1.2 (Processing of the ISR function)….. 13

5.5 Module Internal (Local) Functions 14

5.5.1 Local Function #1 14

5.5.1.1 Design Rationale 14

5.5.1.2 Processing 14

5.5.2 Local Function #2 14

5.5.2.1 Design Rationale 14

5.5.2.2 Processing 14

5.5.3 Local Function #3 15

5.5.3.1 Design Rationale 15

5.5.3.2 Processing 15

5.5.4 Local Function #4 15

5.5.4.1 Design Rationale 15

5.5.4.2 Processing 15

5.5.5 Local Function #5 16

5.5.5.1 Design Rationale 16

5.5.5.2 Processing 16

5.5.6 Local Function #6 16

5.5.6.1 Design Rationale 16

5.5.6.2 Processing 16

5.5.7 Local Function #7 16

5.5.7.1 Design Rationale 17

5.5.7.2 Processing 17

5.5.8 Local Function #8 17

5.5.8.1 Design Rationale 17

5.5.8.2 Processing 17

5.5.8.3 17

5.5.9 Local Function #9 17

5.5.9.1 Design Rationale 18

5.5.9.2 Processing 18

5.5.10 Local Function #10 18

5.5.10.1 Design Rationale 18

5.5.10.2 Processing 18

5.5.11 Local Function #11 18

5.5.11.1 Design Rationale 18

5.5.11.2 Processing 19

5.5.12 Local Function #12 19

5.5.12.1 Design Rationale 19

5.5.12.2 Processing 19

5.6 GLOBAL Function/Macro Definitions 19

6 Known Limitations with Design 20

7 UNIT TEST CONSIDERATION 21

Appendix A Abbreviations and Acronyms 22

Appendix B Glossary 23

Appendix C References 24

Introduction

Purpose

MDD for System Friction Learning

SysFricLrng High-Level Description

Refer FDD

Design details of software module

Refer FDD

Graphical representation of SysFricLrng

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
INDEX0_CNT_U08	1	CNT	0U
INDEX1_CNT_U08	1	CNT	1U
INDEX2_CNT_U08	1	CNT	2U
INDEX3_CNT_U08	1	CNT	3U
SYSSATNFRICESTIMDMIN_HWNWMTR_F32	1	HwNwMtr	0.0F
SYSSATNFRICESTIMDMAX_HWNWMTR_F32 2	1	HwNwMtr	20.0F
SYSFRICESTIMDMIN_HWNWMTR_F32	1	HwNwMtr	0.0F
SYSFRICESTIMDMAX_HWNWMTR_F32	1	HwNwMtr	20.0F
SYSFRICOFFSMIN_HWNWMTR_F32	1	HwNwMtr	-5.0F
SYSFRICOFFSMAX_HWNWMTR_F32	1	HwNwMtr	5.0F

For rest of the constants, please refer Data Dictionary

Software Component Implementation

The detailed design of the function is provided in the FDD.

Sub-Module Functions

Init: SysFricLrngInit1

Design Rationale

In MDD, filters are initialized inside the for loop using switch case but in code filters are initialized one by one without any conditions.

In model, filters are initialized twice as it is not possible to use a variable for the filter initialization in the model. This is redundancy is not present in the code as variables are used for initializing the filters.

Module Outputs

Refer FDD

Per: SysFricLrngPer1

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

Server Runnable Name

ClrFricLrngOperMod

Design Rationale

Refer FDD

(Processing of function)………

On server invocation call

Server Runnables

Server Runnable Name

GetFricLrngData

Design Rationale

Refer FDD

(Processing of function)………

On server invocation call

Server Runnable Name

GetFricOffsOutpDi

Design Rationale

Refer FDD

(Processing of function)………

On server invocation call

Server Runnable Name

InitFricLrngTbl

Design Rationale

Refer FDD

(Processing of function)………

On server invocation call

Server Runnable Name

SetFricLrngDatal

Design Rationale

Refer FDD

(Processing of function)………

On server invocation call

Server Runnable Name

SetFricOffsOutpDi

Design Rationale

Refer FDD

(Processing of function)………

On server invocation call

Server Runnable Name

GetFricData

Design Rationale

Refer FDD

To avoid calculating array indexing for updating PIMs Rte_Pim_FricLrngData()->Hys and Rte_Pim_FricLrngData()->RngCntr, performed casting the array argument back to it's actual type (similar to what we do with cal arrays) so we can use normal indexing.

(Processing of function)………

On server invocation call

Server Runnable Name

SetFricData

Design Rationale

Refer FDD

To avoid calculating array indexing for updating from PIMs Rte_Pim_FricLrngData()->Hys and Rte_Pim_FricLrngData()->RngCntr, performed casting the array argument back to it's actual type (similar to what we do with cal arrays) so we can use normal indexing.

(Processing of function)………

On server invocation call

Server Runnable Name

FricLrngShtDwn

Design Rationale

Refer FDD

(Processing of function)………

Interrupt Functions

None

Interrupt Function Name

None

Design Rationale

NA

(Processing of the ISR function)…..

NA

Module Internal (Local) Functions

Local Function #1

Function Name	FricLearning	Type	Min	Max
Arguments Passed	SelHwAg_HwDeg_T_f32	Float32	-1440.0	1440.0
	SelColTq_HwNwtMtr_T_f32	Float32	-10	10
	VehSpdIdx_Cnt_T_u16	Uint16	0	3
	HwVelDir_Cnt_T_u08	Uint8	0	1
	LrngEna_Cnt_T_Logl	Boolean	FALSE	TRUE
Return Value	NA	NA	NA	NA

Design Rationale

Processing

Refer to ‘FricLearning’ subsystem in FDD.

Following per instance data is updated.

*Rte_Pim_RawAvrg() (Min:0, Max:20)

Rte_Pim_SatnAvrgFric()[VehSpdIdx_Cnt_T_u16] (Min:0, Max:20)

Also writes the outputs SysFricEstimd and SysSatnFricEstimd

Local Function #2

Function Name	RunningAndCalibrationModes	Type	Min	Max
Arguments Passed	*FricOffs_HwNwtMtr_T_f32	Float32	-5.0	+5.0
	*LrngEna_Cnt_T_Logl	Boolean	FALSE	TRUE
Return Value	None	NA	NA	NA

Design Rationale

Processing

Following PIMs are updated; refer to ‘RunningAndCalibrationModes’ subsystem in the FDD. FricOffs_HwNwtMtr_T_f32 is the output of this function

Rte_Pim_FricLrngData()->FricOffs (Min:-5, Max:5)

*Rte_Pim_RawAvrg() (Min:0, Max:20)

Rte_Pim_SatnAvrgFric()[VehSpdIdx_Cnt_T_u16] (Min:0, Max:20)

Also updates the input argument, *FricOffs_HwNwtMtr_T_f32.

Local Function #3

Function Name	RawAvrgCalc	Type	Min	Max
Arguments Passed	VehSpdIdx_Cnt_T_u16	Uint16	0	5
	DeltaIdxOffsDec_Cnt_T_u16	Uint16	0	12
	DeltaIdxOffsInc_Cnt_T_u16	Uint16	0	13
	TotalCounter_Cnt_T_u32	Uint32	0	65535
	LrngEna_Cnt_T_Logl	Boolean	FALSE	TRUE
Return Value	NA	NA	NA	NA

Design Rationale

Processing

Refer to ‘Raw Average Calculation’ subsystem in FDD.

Following per instance data is updated.

*Rte_Pim_RawAvrg() (Min:0, Max:20)

Rte_Pim_SatnAvrgFric()[VehSpdIdx_Cnt_T_u16] (Min:0, Max:20)

Local Function #4

Function Name	PhiCalc	Type	Min	Max
Arguments Passed	SelHwAg_HwDeg_T_f32	Float32	-1440	1440
	Gate_Cnt_T_u16	Uint16	0	65535
	DeltaIdxOffs_Cnt_T_u16	Uint16	0	10
	SelColTq_HwNwtMtr_T_f32	Float32	-10	10
Return Value	NA	NA	NA	NA

Design Rationale

Processing

Refer to ‘Raw Average Calculation’ subsystem in FDD.

Following per instance data is updated.

Rte_Pim_FricLrngData()->Hys[DeltaIdxOffs_Cnt_T_u16][Gate_Cnt_T_u16 + 1U] (Min:-127, Max:127)

Rte_Pim_FricLrngData()->Hys[DeltaIdxOffs_Cnt_T_u16][Gate_Cnt_T_u16] (Min:-127, Max:127)

Local Function #5

Function Name	RangeCounterManager	Type	Min	Max
Arguments Passed	DeltaIdxOffs_Cnt_T_u16	Uint16	0	10
	DeltaIdxOffsDec_Cnt_T_u16	Uint16	0	12
	DeltaIdxOffsInc_Cnt_T_u16	Uint16	0	13
	Gate_Cnt_T_u16	Uint16	0	65535
Return Value	NA	NA	NA	NA

Design Rationale

Processing

Refer to ‘Range counter manager’ subsystem in FDD.

Following per instance data is updated.

*Rte_Pim_ RngCntrThdExcdd() (Min:0, Max:1)

Rte_Pim_FricLrngData->RngCntr (:,:) (Min:0, Max:65535)

Local Function #6

Function Name	NTCSetReset	Type	Min	Max
Arguments Passed	MaxRawAvrgFric_Cnt_T_f32	Float32	-127	254
Return Value	NA	NA	NA	NA

Design Rationale

Processing

Refer to ‘NTC_Pass’ and ‘NTC_Fail’ subsystem in FDD

Sets or resets the NTCNR_0X0A2

Local Function #7

Function Name	ClearingMode	Type	Min	Max
Arguments Passed	none	NA	NA	NA
Return Value	none	NA	NA	NA

Design Rationale

Processing

Refer to ‘Clearing Mode’ subsystem in FDD.

Following per instance data is updated.

*Rte_Pim_FricOffs()(Min:-5, Max:5)

Local Function #8

Function Name	ResettingMode	Type	Min	Max
Arguments Passed	*FricOffs_HwNwtMtr_T_f32	NA	NA	NA
Return Value	None	NA	NA	NA

Design Rationale

Processing

Refer to ‘ResettingMode’ subsystem in FDD.

Following per instance data is updated. Also updates the input argument ‘*FricOffs_HwNwtMtr_T_f32’.

Rte_Pim_FricLrngData()->RngCntr(;)

Rte_Pim_AvrgFricLpFilX()->FilSt (X: 1 to 4)

Rte_Pim_FricLrngData()->Hys(;)

Rte_Pim_FricOffs()(Min:-5, Max:5)

Rte_Pim_VehBasLineFric()[] (Min:-0, Max:127)

Rte_Pim_RawAvrgFric()[] (Min:--127, Max:254)

Rte_Pim_FilAvrgFric()[] (Min:--10 , Max: 10)

Rte_Pim_SatnAvrgFric()[](Min:--127, Max:254)

Rte_Pim_FricLrngData()->VehLrndFric[] (0-127)

Local Function #9

Function Name	HwAngConstraint	Type	Min	Max
Arguments Passed	FilHwAg_HwDeg_T_f32	Float32	-1440	1440
	*HwAgOK_Cnt_T_Logl	boolean	0	1
	*SelHwAg_HwDeg_T_f32	Float32	-1440	1440
Return Value	NA	NA	NA	NA

Design Rationale

IDXSELN2_ULS_U08 is not used in the code because it is not required instead IDXSELN1_ULS_U08 serves the purpose.

Processing

Refer to ‘HwAngConstraint‘ subsystem in FDD. Updates the input arguments, *HwAgOK_Cnt_T_Logl and *SelHwAg_HwDeg_T_f32

Local Function #10

Function Name	HwVelConstraint	Type	Min	Max
Arguments Passed	HwVel_HwRadPerSec_T_f32	Float32	-42	42
	HwVelOK_Cnt_T_Logl	Boolean	0	1
	HwVelDir_Cnt_T_u08	Uint8	0	1
Return Value	NA	NA	NA	NA

Design Rationale

Processing

Refer to ‘HwVelConstraint’ subsystem in FDD.

Local Function #11

Function Name	VehSpdConstraint	Type	Min	Max
Arguments Passed	VehSpd_Kph_T_f32	Float32	0	511
	*VehSpdOK_Cnt_T_Logl	Boolean	0	1
	*VehSpdIdx_Cnt_T_u16	Uint16	0	5
Return Value	None	NA	NA	NA

Design Rationale

Code is optimized due to limitation with the model; hence code completely won’t match the model. There won’t be any impact on the functionality.

In the model as it is not possible to break the for loop until the loop iterator reaches the configured constant threshold value, index corresponding to the position in ‘SysFricLrngVehSpd’ which breaches the conditions mentioned in ‘VehSpdIdxCalcn’ subsystem is calculated by successively adding the index value after multiplying it with either the condition true or false based on whether the vehicle speed value breaches the threshold mentioned in the FDD. In code as it is possible to exit the for loop as soon as a value in ‘VehSpdIdxCalcn’ breaches thresholds as mentioned in FDD, no such successive addition of loop counter is required.

Processing

Refer to ‘VehSpdConstraint’ subsystem in FDD.

Local Function #12

Function Name	ColTqconstraint	Type	Min	Max
Arguments Passed	FilColTq_HwNwtMtr_T_f32	Float32	-10	10
Arguments Passed	*SelColTq_HwNwtMtr_T_f32	Boolean	-10	10
Return Value	NA	NA	NA	NA

Design Rationale

Processing

Refer to ‘ColTqconstraint’ subsystem in FDD. Updates the *SelColTq_HwNwtMtr_T_f32.

GLOBAL Function/Macro Definitions

NA

Known Limitations with Design

None

UNIT TEST CONSIDERATION

In model, one based indexing is used but in code 0 based indexing is used.
In the NVM block needs area of Developer tool, the options of "Restore at Startup" and "Store at Shutdown" are disabled as the newer version (3.13.22 SP2) of this tool throws warnings while doing a DCF check.
There will be a source model mismatch that occurs because of a logic change that happened for a PSR. There is limiting that occurs in the new Non Rte Server Runnable. These limits were switched for the PSR but this change was not brought in for the design. An ICR has been submitted to fix the design to match the implementation, EA4#15920.

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)	Process 4.02.01
2	MDD Guideline	Process 4.02.01
3	Software Naming Conventions.doc	2.0
4	Software Design and Coding Standards.doc	2.1
5	FDD- SF007A_SysFricLrng_Design	See Synergy sub project version

40.3 - SysFricLrng_PeerReviewChecklists

Overview

Summary Sheet
Synergy Project
PolySpace

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

SysFricLrng

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

SF007A_SysFricLrng_Impl_3.0.1

Change Owner:

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

Matthew Leser

Work CR ID:

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

EA4#18370

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

N/A

MDD

N/A

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

Implementation update was strictly to bring in new design version. Polyspace was run for updated Rte_Stubs.h file

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:

Matthew Leser

Review Date :

01/15/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

SysFricLrng.c

Source File Revision:

9

Source File Name:

SysFricLrngNonRte.c

Source File Revision:

1

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)

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:

Matthew Leser

Review Date :

01/15/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

41 - Component Implementation

Component Implementation

Component Documentation

SysGlbPrm Review.html

41.1 - SysGlbPrm 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. SF999A_SysGlbPrm_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. SF999A_SysGlbPrm_Impl_1.3.0

Change Owner:

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

Work CR ID:

EA4#3935

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:

MDD

Yes

Source Code

Yes

PolySpace

Integration Manual

Davinci Files

Comments:

Only reviewed 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:

Nick Saxton

Review Date :

02/19/16

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:

N/A

Source File Revision:

N/A

Header File Name:

SysGlbPrm.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:

N/A

FDD/SCIR/DSR/FDR/CM Name:

SF999A_SysGlbPrm_Design

Revision:

1.4.0

Quality Check Items:

Rationale is required for all answers of No

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

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:

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

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:

Nick Saxton

Review Date :

02/19/16

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:

SysGlbPrm.h

Source File Revision:

3

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

N/A

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

No justifications

Do all MISRA deviation comments use approved

N/A

Comments:

deviation tags

No deviations

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 :

02/19/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

42 - Component Implementation

Component Implementation

Component Documentation

42.1 - SysPrfmncSts_IntegrationManual

Integration Manual

For

SysPrfmncSts

VERSION: 1.0

DATE: 20-JAN-2017

Prepared By:

SW component 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-Jan-17

Table of Contents

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

3 Dependencies 7

3.1 SWCs 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	EA4 Software Naming Conventions.doc	01.00.00
2	Software Design and Coding Standards.doc	2.1
3	SF059A_SysPrfmncSts_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

Pleas refer DataDict.m file

Required Global Data Outputs

Pleas refer DataDict.m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
SysPrfmncStsInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
SysPrfmncStsPer1	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

42.2 - SysPrfmncSts_MDD

Module Design Document

For

SysPrfmncSts

Jan 19, 2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

SW Component group,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Krishna Anne	1.0	20-Jan-2017

Table of Contents

2 SysPrfmncSts & High-Level Description 5

3.1 Graphical representation of SysPrfmncSts 6

5.1.1 Init: SysPrfmncStsInit1 8

5.1.2 Per: SysPrfmncStsPer1 8

5.1.1.2 Module Outputs 8

5.1.2.1 Design Rationale 8

5.1.2.2 Store Module Inputs to Local copies 8

5.4.1 Local Function #1 8

5.4.1.1 Design Rationale 9

5.4.1.2 Processing 9

5.4.2 Local Function #2 9

5.4.2.1 Design Rationale 9

5.4.2.2 Processing 9

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

Introduction

Please refer the Design Subproject.

SysPrfmncSts & High-Level Description

Please refer the Design Subproject.

Design details of software module

Please refer the Design Subproject.

Graphical representation of SysPrfmncSts

Data Flow Diagram

Please refer the Design Subproject.

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
Please refer the .m file in the design Subproject.	NA	NA	NA

Software Component Implementation

Sub-Module Functions

None

Init: SysPrfmncStsInit1

Design Rationale

None

Module Outputs

None

Per: SysPrfmncStsPer1

Design Rationale

None

Store Module Inputs to Local copies

None

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	PrfmncSysSt1	Type	Min	Max
Arguments Passed	SysSt_Val_Cnt_T_enum	SysSt1	0U	3U
	ThermDutyCycProtnTDptLim_MotNwtMtr_T_f32	float32	0.0F	8.8F
	ThermDutyCycProtnLoadDptLim_MotNwtMtr_T_f32	float32	0.0F	8.8F
	StallMotTqLim_MotNwtMtr_T_f32	float32	0.0F	8.8F
	*SysPrfmncSt_Cnt_T_u16	uint16	0U	36702U
Return Value	NA	NA	NA	NA

Design Rationale

None

Processing

Please refer below path in FDD.

SF059A_SysPrfmncSts/SysPrfmncSts/SysPrfmncStsPer1/PrfmncSysSt

Local Function #2

Function Name	PrfmncSysSt2	Type	Min	Max
Arguments Passed	DutyCycThermProtnMaxOutp_Uls_T_u16	uint16	0U	200U
	EcuTFild_DegCgrd_T_f32	float32	-50.0F	50.0F
	LoaSt_Val_Cnt_T_enum	LoaSt1	0U	5U
	VehSpdVld_Cnt_T_logl	Boolean	FALSE	TRUE
	*SysPrfmncSt_Cnt_T_u16	uint16	0U	36702U
Return Value	NA	NA	NA	NA

Design Rationale

None

Processing

Please refer below path in FDD.

SF059A_SysPrfmncSts/SysPrfmncSts/SysPrfmncStsPer1/PrfmncSysSt

Known Limitations with Design

NTC definitions are missed in the .m file of the design. FDD owner agreed to include them in the next revision.

Anomaly EA4#9446 is raised.

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 : SF059A_SysPrfmncSts_Design	See synergy sub-project version

42.3 - SysPrfmncSts_PeerReviewChecklists

Overview

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. SF059A_SysPrfmncSts_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. SF059A_SysPrfmncSts_Impl_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. Krishna Anne

Work CR ID:

EA4#7019

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:

PS : Anomaly EA4#9446 is raised on design.

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/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

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:

Initial version

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:

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:

Krishna Anne

Review Date :

01/20/17

Component Type :

Application

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

SysPrfmncSts.c

Source File Revision:

1

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:

SysPrfmncSts_MDD

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF059A_SysPrfmncSts_Design

Revision:

1.1.0

Quality Check Items:

Rationale is required for all answers of No

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

Krishna Anne

Review Date :

01/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

SysPrfmncSts_MDD

MDD Revision:

1

Source File Name:

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

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:

Krishna Anne

Review Date :

01/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

SysPrfmncSts.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 TL108A_PolyspaceSuprt

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 NA

QAC version:

Windows User: eg 8.1.1-R TL100A_QACSuprt

QAC sub project version:

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

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:

Krishna Anne

Review Date :

01/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

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

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:

Krishna Anne

Review Date :

01/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Matt Leser

43 - Component Implementation

Component Implementation

Component Documentation

43.1 - TEstimn_IntegrationManual

Integration Manual

For

TEstimn

VERSION: 2.0

DATE: 07-Dec-2017

Prepared By:

Matt 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	Sankardu Varadapureddi	1.0	17-Sep-2015
2	Added Nvm Block	Matthew Leser	2.0	07-Dec-2017

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

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 : SF006A_ TEstimn_Design	See Synergy sub project version
2	Software Naming Conventions	Process 4.04.00
3	Software Design and Coding Standards	Process 4.04.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
TEstimnInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
TEstimnPer1	None	RTE (100 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

TFilStVal Compiler Settings

Preprocessor MACRO

None.

Optimization Settings

None.

Appendix

None

43.2 - TEstimn_MDD

Module Design Document

For

TEstimn

06-Apr-2018

Prepared By:

Shawn Penning,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Sankardu Varadapureddi	1	17-Sep-2015
Updated to Design v2.2.0	Matthew Leser	2	26-Apr-2017
Updated Graph and added new local function	Matthew Leser	3	06-Dec-2017
Added local constants and unit test considerations.	SPP	4	06-Apr-2018

Table of Contents

2 TEstimn High-Level Description 5

3.1 Graphical representation of TEstimn 6

5.1.1 Init: TEstimnInit1 9

5.1.2 Per: TEstimnPer1 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace
help
Version History

Introduction

Purpose

Scope

TEstimn High-Level Description

Refer to FDD

Design details of software module

Graphical representation of TEstimn

Data Flow Diagram

Refer FDD

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Refer .m file

Local Constants

#define TESTIMNASSIMECHTHILIM_DEGCGRD_F32 150.0F

#define TESTIMNASSIMECHTLOLIM_DEGCGRD_F32 (-50.0F)

#define TESTIMNFETTHILIM_DEGCGRD_F32 200.0F

#define TESTIMNFETTLOLIM_DEGCGRD_F32 (-50.0F)

#define TESTIMNMAGTHILIM_DEGCGRD_F32 150.0F

#define TESTIMNMAGTLOLIM_DEGCGRD_F32 (-50.0F)

#define TESTIMNWIDGTHILIM_DEGCGRD_F32 300.0F

#define TESTIMNWIDGTLOLIM_DEGCGRD_F32 (-50.0F)

#define DUALECUSTSIDX_CNT_U08 ((uint8)0U)

#define SNGECUSTSIDX_CNT_U08 ((uint8)1U)

#define EXPCOEFF_ULS_F32 (-1.0F)

#define SILLFILVALMIN_ULS_F32 (-2431500.0F)

#define SILLFILVALMAX_ULS_F32 (1001200.0F)

#define SILPFILVALMIN_ULS_F32 (0.0F)

#define SILPFILVALMAX_ULS_F32 (62500.0F)

#define ASSIMECHLLFILVALMIN_ULS_F32 (-4577000.0F)

#define ASSIMECHLLFILVALMAX_ULS_F32 (1716400.0F)

#define ASSIMECHLPFILVALMIN_ULS_F32 (0.0F)

#define ASSIMECHLPFILVALMAX_ULS_F32 (1764.0F)

#define CULLFILVALMIN_ULS_F32 (-2431500.0F)

#define CULLFILVALMAX_ULS_F32 (1001200.0F)

#define CULPFILVALMIN_ULS_F32 (0.0F)

#define CULPFILVALMAX_ULS_F32 (62500.0F)

#define MAGLLFILVALMIN_ULS_F32 (-2431500.0F)

#define MAGLLFILVALMAX_ULS_F32 (1001200.0F)

#define MAGLPFILVALMIN_ULS_F32 (0.0F)

#define MAGLPFILVALMAX_ULS_F32 (62500.0F)

#define FILVALMIN_ULS_F32 (0.0F)

#define TESTIMNFETMTGTNIDX_CNT_U08 ((uint8)2U)

#define TESTIMNIGNTIOFFTHD_CNT_F32 (10000.0F)

Software Component Implementation

Sub-Module Functions

Init: TEstimnInit1

Design Rationale

#define FETLOABITMASK_CNT_U08 ((uint8)4U) Refer FDD for the functionality.

Module Outputs

Refer FDD

Per: TEstimnPer1

Design Rationale

In ‘AssistMechanismLeadLagFilterRe-Initialization’ block, blocks ‘AssistMechanismInitEnable’ and ‘AssistMechanismInitDisable’ have similar logic except for some calculations related to inputs. So the differences are implemented in ‘if-else’ statement and common logic is implemented after ‘if-else’ statements in the SW.

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

Function Name	FltMtgtnCalSeln	Type	Min	Max
Arguments Passed	FetLoaMtgtnEna_Cnt_T_logl	boolean	FALSE	TRUE
	DualEcuFltMtgtnEna_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	NA	NA	NA	NA

Design Rationale

Implementation of ‘Fault Mitigation Calibration Selection’ block in FDD (To reduce cyclomatic complexity & path count in Per1).

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

Calculate TEstimnSiLLFilCoeffB0 as per following equation:

TEstimnSiLLFilCoeffB0= -1*[(TEstimnSiLLFilCoeffA1-1)+TEstimnSiLLFilCoeffB1]

Calculate TEstimnCuLLFilCoeffB0 as per following equation:

TEstimnCuLLFilCoeffB0= -1*[(TEstimnCuLLFilCoeffA1-1)+TEstimnCuLLFilCoeffB1]

Calculate TEstimnMagLLFilCoeffB0 as per following equation:

TEstimnMagLLFilCoeffB0= -1*[(TEstimnMagLLFilCoeffA1-1)+TEstimnMagLLFilCoeffB1]

Calculate TEstimnAssiMechLLFilCoeffB0 as per following equation:

TEstimnAssiMechLLFilCoeffB0= -1*[(TEstimnAssiMechLLFilCoeffA1-1)+TEstimnAssiMechLLFilCoeffB1]

Anomaly 20644 Issue 1B and 1C were not addressed due to time considerations. Anomaly 19666 issue 4 is a test issue that should be addressed by test team but does not affect design or 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 (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 : SF006A_ TEstimn_Design	See Synergy sub project version

43.3 - TEstimn_Review

Overview

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

Testimn

Revision / Baseline:

SF006A_Testimn_Impl_3.1.0

Change Owner:

Shawn Penning

Work CR ID:

EA4#22127

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

Yes

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

2

0.5

Component developer reviewers:

0

2

0

6.5

Other reviewers:

0

1

0

Total hours

2

5

0.5

7.5

Content reviewed

Lines of code:

100

Elements of .arxml content:

0

Pages of documentation:

5

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:

Change Owner:

Shawn Penning

Review Date :

04/06/18

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

TEstimn.c

Source File Revision:

4

Header File Name:

Header File Revision:

MDD Name:

TEstimn_MDD.docx

4

SWC Design Name:

SF006A_TEstimn_Design

Synergy version matches change history

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

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.

N/A

Comments:

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

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

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

Yes

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

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

N/A

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: Anomaly 20644 Issue 1B and 1C were not addressed due to time considerations. Anomaly 19666 issue 4 is a test issue that should be addressed by test team but does not affect design or code.

for any SWC Design corrections needed

General Notes / Comments:

Change Owner:

Shawn Penning

Review Date :

04/06/18

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Nakul Shah

Comments:

Integrator and or
SW lead:

Akilan Rathakrishnan

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 4: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

TEstimn_MDD.docx

MDD Revision:

4

Source File Name:

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

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 SWC

N/A

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

Yes

Comments:

General Notes / Comments:

Change Owner:

Shawn Penning

Review Date :

04/06/18

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 5: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

TEstimn.c

Source File Revision:

4

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

1.04.00

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

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)

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)

Codemetrics count OK

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Summary Sheet
Synergy Project

Change Owner:

Shawn Penning

Review Date :

04/06/18

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

44 - Component Implementation

Component Implementation

Component Documentation

44.1 - TqLoa_DesignReview

Overview

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. SF048A_TqLoa_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. SF048A_TqLoa_Impl_1.1.1

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. Matt Leser

Work CR ID:

EA4#8047

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

N/A

Source Code

N/A

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

Quality update to bring in new design 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:

Matt Leser

Review Date :

10/27/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shruthi R

44.2 - TqLoa_IntegrationManual

Integration Manual

For

TqLoa

VERSION: 1.0

DATE: 24-Aug-2015

Prepared By:

Spandana Balani,

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	24-Aug-2015

Table of Contents

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

3 Dependencies 7

3.1 SWCs 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 – SF048A_TqLoa_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

Include NxtrFil.h in Rte_UserTypes.h header file

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

Runnable	Scheduling Requirements	Trigger
TqLoaPer1	None	RTE(2ms)

.

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

44.3 - TqLoa_MDD

Module Design Document

For

TqLoa

Aug 24, 2015

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Spandana Balani,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	SB	1.0	24-Aug-2015

Table of Contents

2 TqLoa & High-Level Description 5

3.1 Graphical representation of TqLoa 6

5.1.1 Init: TqLoaInit1 8

5.1.2 Per: TqLoaPer1 8

Introduction

Purpose

Scope

TqLoa & High-Level Description

Refer FDD

Design details of software module

Refer FDD

Graphical representation of TqLoa

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
INVGRVYTLCON_SECSQDPERMTR_F32	Single precision	SecSqdPerMtr	1.0/9.81
DEADZONEOUTPUT_MOTNWTMTR_F32	Single precision	MotNwtMtr	0

Software Component Implementation

Refer FDD

Sub-Module Functions

Init: TqLoaInit1

Refer FDD

Per: TqLoaPer1

Refer 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

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	Process 04.02.00
5	FDD – SF048A_TqLoa_Design	See Synergy SubProject version

45 - Component Implementation

Component Implementation

Component Documentation

45.1 - TunSelnAuthy_IntegrationManual

Integration Manual

For

TunSelnAuthy

VERSION: 1.0

DATE: 07-OCT-2015

Prepared By:

Nick Saxton,

Nexteer Automotive,

Saginaw, MI, USA

Revision History

Description	Author	Version	Date
Initial version	N. Saxton	1.0	07-Oct-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

Summary Sheet
Davinci Files
Source Code
PolySpace
Synergy Project

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.doc	01.00.00
2	Software Design and Coding Standards.doc	2.1
3	SF023A_ TunSelnAuthy_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
TunSelnAuthyInit1		RTE(Init)

Runnable	Scheduling Requirements	Trigger
RtCalChgReq	None	On event
XcpCalChgReq	None	On event

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

45.2 - TunSelnAuthy_MDD

Module Design Document

For

TunSelnAuthy

June 17, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Krishna Anne,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Date
Initial Version	N. Saxton	09-Oct-2015
Updated as per FDD v1.1.0	Krishna Anne	17-Jun-2016

Table of Contents1 TunSelnAuthy High-Level Description 4

2 Design details of software module 5

2.1 Graphical representation of TunSelnAuthy 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 Init: TunSelnAuthyInit1 7

4.1.1.1 Design Rationale 7

4.1.1.2 Module Outputs 7

4.2 Server Runables 7

4.2.1 RtCalChgReq 7

4.2.1.1 Design Rationale 7

4.2.1.2 (Processing of function)……… 7

4.2.2 XcpCalChgReq 7

4.2.2.1 Design Rationale 7

4.2.2.2 (Processing of function)……… 7

4.3 Interrupt Functions 7

4.3.1 Interrupt Function Name 7

4.4 Module Internal (Local) Functions 7

4.5 GLOBAL Function/Macro Definitions 7

5 Known Limitations with Design 9

6 UNIT TEST CONSIDERATION 10

Appendix A Abbreviations and Acronyms 11

Appendix B Glossary 12

Appendix C References 13

TunSelnAuthy High-Level Description

Refer FDD

Design details of software module

Refer FDD

Graphical representation of TunSelnAuthy

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

Software Component Implementation

Sub-Module Functions

Init: TunSelnAuthyInit1

Design Rationale

Refer FDD

Module Outputs

None

Server Runables

RtCalChgReq

Design Rationale

Refer FDD

(Processing of function)………

Refer FDD

XcpCalChgReq

Design Rationale

Refer FDD

(Processing of function)………

Refer FDD

Interrupt Functions

None

Interrupt Function Name

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	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.1
5	FDD – SF023A_TunSelnAuthy_Design	See Synergy subproject version

45.3 - TunSelnAuthy_PeerReview

Overview

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. SF023A_TunSelnAuthy_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. SF023A_TunSelnAuthy_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. Brendon Binder

Work CR ID:

EA4#12457

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

No

Source Code

No

PolySpace

N/A

Integration Manual

No

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

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

Yes

Comments:

Not changed

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 :

06/22/17

Component Type :

Application

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:

TunSelnAuthy.c

Source File Revision:

3

Header File Name:

TunSelnAuthy.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:

TunSelnAuthy_MDD.docx

Revision:

2

FDD/SCIR/DSR/FDR/CM Name:

SF023A_TunSelnAuthy_Design

Revision:

1.1.0

Quality Check Items:

Rationale is required for all answers of No

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

Requirements Traceability tags were removed

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

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

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:

Brendon Binder

Review Date :

06/22/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:

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

N/A

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

N/A

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 :

06/22/17

Lead Peer Reviewer:

Krishna Anne

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 :

06/22/17

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

46 - Component Implementation

Component Implementation

Component Documentation

46.1 - VehSigCdng_Integration Manual

Integration Manual

For

VehSigCdng

VERSION: 1.0

DATE: 13-July-2015

Prepared By:

Spandana Balani

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	13-jul-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

5.3 file Specific Include Path present 8

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

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 4.01.00
<2>	<Software Naming Conventions>	Process 4.01.00
<3>	<Coding standards>	Process 4.01.00
<4>	<FDD SF033A_VehSigCdng_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

None

Configuration REQUIREMeNTS

Build Time Config

Constants	Notes
FLTINJENA	Set to STD_ON for Fault injection

Configuration Files to be provided by Integration Project

Include NxtrFil.h in Rte_UserTypes.h header file.

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

file Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
VehSigCdngInit1	On Init	Rte_Init

Runnable	Scheduling Requirements	Trigger
VehSigCdngPer1	None	RTE(2ms)

.

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

46.2 - VehSigCdng_MDD

Module Design Document

For

VehSigCdng

Sep 20, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Spandana Balani
Change History

Sl. No.	Description	Author	Version	Date
1	Initial Version	SB	1	13-Jul-2015
2	Updated for FDD v2.0.0	NS	2	2-Jun-2016
3	Updated for FDD v2.2.0	SB	3	20-Sep-2016

Table of Contents

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 VehSigCdng High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of VehSigCdng 6

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.1 Sub-Module Functions 10

5.1.2 Interrupt Service Routines 10

5.1.3 Server Runnable Functions 10

5.1.4 Module Internal (Local) Functions 10

5.1.5 Transition Functions 11

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

VehSigCdng High-Level Description

Refer to FDD

Design details of software module

Graphical representation of VehSigCdng

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

See .m file

Software Component Implementation

Sub-Module Functions

Initialization sub-module VehSigCdngInit1()

Periodic sub-module VehSigCdngPer1()

Design Rationale - Fault Injection client call is conditional compiled based on “FLTINJENA” build constant.

Interrupt Service Routines

None

Server Runnable Functions

None

Module Internal (Local) Functions

Local Function #1

Refer to VehSpd block in the model

Function Name	VehSigCdng_VehSpd	Type	Min	Max
Arguments Passed	VehSpdSerlCom_Kph_T_f32	Float32	0	511
	VehSpdVldSerlCom_Cnt_T_lgc	Boolean	FALSE	TRUE
	VehSpdOvrd_Kph_T_f32	Float32	0	511
	VehSpdOvrdVld_Cnt_T_logl	Boolean	FALSE	TRUE
	VehSpd_Kph_T_f32	Float32	0	511
	VehSpdVld_Cnt_T_logl	Boolean	FALSE	TRUE
Return Value	N/A

Notes: VehSpd_Kph_T_f32, VehSpdVld_Cnt_T_logl are the outputs of the function

Local Function #2

Refer to VehLgtA block in the model

Function Name	VehSigCdng_VehLgtA	Type	Min	Max
Arguments Passed	VehLgtASerlCom_MpSecSq_T_f32	Float32	-180	180
	VehLgtAVldSerlCom_Cnt_T_lgc	Boolean	FALSE	TRUE
	VehLgtA_KphpS_T_f32	Float32	-50	50
	VehLgtAVld_Cnt_T_logl	Boolean	FALSE	TRUE
Return Value	(if no value returned, write N/A)

Notes: VehLgtA_KphpS_T_f32, VehLgtAVld_Cnt_T_logl are the outputs of the function

Local Function #3

Refer to VehLatA block in the model

Function Name	VehSigCdng_VehLatA	Type	Min	Max
Arguments Passed	VehLatASerlCom_MpSecSq_T_f32	Float32	-10	10
	VehLatAVldSerlCom_Cnt_T_lgc	Boolean	FALSE	TRUE
	VehLatA_MpSecSq_T_f32	Float32	-10	10
	VehLatAVld_Cnt_T_logl	Boolean	FALSE	TRUE
Return Value	(if no value returned, write N/A)

Notes: VehLatA_MpSecSq_T_f32, VehLatAVld_Cnt_T_logl are the outputs of the function

Local Function #4

Refer to VehYawRate block in the model

Function Name	VehSigCdng_VehYawRate	Type	Min	Max
Arguments Passed	VehYawRateSerlCom_DegpS_T_f32	Float32	-120	120
	VehYawRateVldSerlCom_Cnt_T_lgc	Boolean	FALSE	TRUE
	VehYawRate_DegpS_T_f32	Float32	-120	120
	VehYawRateVld_Cnt_T_logl	Boolean	FALSE	TRUE
Return Value	(if no value returned, write N/A)

Notes: VehYawRate_DegpS_T_f32, VehYawRateVld_Cnt_T_logl are the outputs of the function

Local Function #5

Refer to “Lateral Acceleration Estimation” block in the model

Function Name	VehSigCdng_LatAEstmn	Type	Min	Max
Arguments Passed	VehYawRate_DegpS_T_f32	Float32	-120	120
	VehYawRateVld_Cnt_T_lgc	Boolean	FALSE	TRUE
	VehSpd_Kph_T_f32	Float32	0	511
	VehSpdVld_Cnt_T_logl	Boolean	FALSE	TRUE
	VehLatAEstimd_MtrPerSecSqd_T_f32	Float32	-10	10
	VehLatAEstimdVld_Cnt_T_logl	Boolean	FALSE	TRUE
Return Value	(if no value returned, write N/A)

Notes: VehLatAEstimd_MtrPerSecSqd_T_f32, VehLatAEstimdVld_Cnt_T_logl are the outputs of the function

Transition Functions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

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 – SF033A_VehSigCdng_Design	See Synergy Sub project version

46.3 - VehSigCdng_PeerReviewChecklist

Overview

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. SF033A_VehSigCdng_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. SF033A_VehSigCdng_Impl_2.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#12459

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 :

07/13/17

Lead Peer Reviewer:

Brendon Binder

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:

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

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/13/17

Component Type :

CDD

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

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:

VehSigCdng.c

Source File Revision:

9

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:

VehSigCdng_MDD.docx

Revision:

5

FDD/SCIR/DSR/FDR/CM Name:

SF033A_VehSigCdng_Design

Revision:

2.3.0

Quality Check Items:

Rationale is required for all answers of No

Summary Sheet
Synergy Project

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

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:

Need to compile for Std_Off and Std_On; Done, left in STD_OFF

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 :

07/14/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

Sheet 5: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

VehSigCdng.c

Source File Revision:

9

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/14/17

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Brionna Spencer

47 - Component Implementation

Component Implementation

Component Documentation

47.1 - VehSpdLimr_DesignReview

Overview

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. SF016A_VehSpdLimr_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. SF016A_VehSpdLimr_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. Nick Saxton

Work CR ID:

EA4#5502

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:

MDD

Source Code

PolySpace

Integration Manual

Davinci Files

Comments:

Bringing in new design project to match up with implementation

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 :

04/26/16

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

47.2 - VehSpdLimr_IntegrationManual

Integration Manual

For

SF016A VehSpdLimr

VERSION: 1.0

DATE: 11-Aug-2015

Prepared By:

Sarika Natu,

KPIT Technologies,

India

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

Revision History

Description	Author	Version	Date
Initial version	Sarika Natu	1.0	11-Aug-2015

Table of Contents

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

4.2 Configuration Files to be provided by Integration Project 7

1 VehSpdLimr High-Level Description 4

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	Software Process Release 04.02.00
2	Software Naming Conventions	Software Process Release 04.02.00
3	Design and Coding standards	Software Process Release 04.02.00
4	FDD – SF016A_VehSpdLimr_Design	See Synergy sub project 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
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
NA	None	RTE/ISR(<time>ms)

Runnable	Scheduling Requirements	Trigger
VehSpdLimrPer1	None	RTE (2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
VehSpdLimr_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>

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

47.3 - VehSpdLimr_MDD

Module Design Document

For

VehSpdLimr

August 10, 2015

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Sarika Natu ,

KPIT Technologies,

India
Change History

Description	Author	Version	Date
Initial Version	Sarika Natu(KPIT Technologies)	1.0	10-Aug-2015

Table of Contents

2.1 Graphical representation of VehSpdLimr 5

4.1 Sub-Module Functions 7

4.1.1 Init: VehSpdLimr_Init 7

4.1.1.1 Design Rationale 7

4.1.1.2 Module Outputs 7

4.1.2 Per: VehSpdLimr_Per1 7

4.1.2.1 Design Rationale 7

4.1.2.2 Store Module Inputs to Local copies 7

4.1.2.3 (Processing of function)……… 7

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