Sr. No.	Title	Version
1	EA4 Software Naming Conventions	1.0.3 draft
2	Software Design and Coding Standards	3.0 draft
3	SF072A_ClsdLoopDampg_Design	See Synergy Sub Project 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

Note: There is a global Non-Rte function ClsdLoopDmpg_Init. This init function is generated by embedded coder and is not present in the Simulink model. This function is always empty and shall not be called.

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 FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
ClsdLoopDampgInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
ClsdLoopDampgPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
ClsdLoopDampg_START_SEC_CODE	Code

* 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

1.2 - ClsdLoopDampg_MDD

Module Design Document

For

ClsdLoopDampg

April 05, 2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

TATA ELXSI,

INDIA

Change History

Sl. No.

Description

Author

Version

Date

1

Initial version

Krzysztof Byrski

1

27-Feb-2018

2

Updated to add the additional _Init function generated for autocode in Section 5.

Updated to add additional local constants required for autocode in Section 4.1.1.1

Vipin David

2

05-Apr-2018

Table of Contents1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 ClsdLoopDampg & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of ClsdLoopDampg 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: ClsdLoopDampgInit1 8

5.1.2 Init: ClsdLoopDampg_Init 8

5.1.3 Per: ClsdLoopDampgPer1 8

5.2 Server Runables 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 10

7 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 14

Introduction

Purpose

Module Design Document for SF072A_ClsdLoopDampg_Impl.

Scope

The following definitions are used throughout this document:

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

ClsdLoopDampg & High-Level Description

This function produces a handwheel reference torque for the closed loop system. This function calculates damping torque based on motor velocity and scaled by factors such a rack force estimation. Closed Loop Damping shall be calibrated based on vehicle speed, and motor velocity. End of Travel shall affect the output signal command based on the EoT State, EoT Delta Angle and EoT Assist Scale.

Design details of software module

Graphical representation of ClsdLoopDampg

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 SF072A_ClsdLoopDampg_DataDict.m for details.

Software Component Implementation

Sub-Module Functions

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

Init: ClsdLoopDampgInit1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Init: ClsdLoopDampg_Init

Design Rationale

This init function is generated by embedded coder and is not present in the Simulink model.

This function is always empty and is not called.

Module Outputs

There are no outputs for this function.

Per: ClsdLoopDampgPer1

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

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

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

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

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

1.3 - ClsdLoopDampg_Review

Overview

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

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

ClsdLoopDampg

Revision / Baseline:

SF072A_ClsdLoopDampg_AGC_Impl_2.0.0

Change Owner:

Nimmy Mathews

Work CR ID:

EA4#20917

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

Yes

Integration Manual

Yes

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

1

0

Component developer reviewers:

0

1

0

3

Other reviewers:

0

Total hours

1

2

0

3

Content reviewed

Lines of code:

200

Elements of .arxml content:

1

Pages of documentation:

24

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:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

04/16/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Davinci Files

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

N/A

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

N/A

Comments:

Do all port interface names end in PortIf and a sequence

N/A

Comments:

number

Non-program-specific components saved

N/A

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

N/A

Comments:

versions (If available) and changes match changes

Initial version

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

N/A

Comments:

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

Initial version

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

The init value of DampgCmdSca is changed from 0 to 1

Naming conventions followed. All names should

N/A

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

N/A

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

N/A

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

The init value of DampgCmdSca is changed from 0 to 1

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

removed

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

N/A

Comments:

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

Runnable calling frequencies match DataDict.m file

N/A

Comments:

Runnable port access matches the DataDict.m file

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

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

Per Instance Memory names and data types

N/A

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

The only change from the previous version is that the init value of DampgCmdSca has changed from 0 to 1

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

04/16/18

Component Type :

Application

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

Sheet 4: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

ClsdLoopDampg.c

Source File Revision:

2

Header File Name:

ClsdLoopDampg.h

Header File Revision:

1

MDD Name:

ClsdLoopDampg_MDD.docx

Revision:

2

SWC Design Name:

SF072A_ClsdLoopDampg_AGC_Design

Revision:

2.0.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version:1.0.1

EA4 Software Naming Convention followed:

Version:1.0.3 draft

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

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

Initial version

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

No

Comments:

and Version Control version in file comment block

Need new rules for autocoding

Change log contains detailed description of changes

No

Comments:

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

Need new rules for autocoding

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

N/A

Comments:

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

Initial version

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

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

Code comments are clear, correct, and adequate

Yes

Comments:

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

Comments are autogenerated.Need new rules for autocoding

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]

Need new rules for autocoding

Function comment blocks are per standards and

No

Comments:

contain correct information: [N43]

Need new rules for autocoding

Code formatting (indentation, placement of

Yes

Comments:

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

As per the draft version 3.0

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

As per the draft version 3.0

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,

Yes

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

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

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

04/16/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 5: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

ClsdLoopDampg_MDD.docx

MDD Revision:

2

Source File Name:

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

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

04/16/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

ClsdLoopDampg.c

Source File Revision:

2

Source File Name:

-

Source File Revision:

-

Source File Name:

-

Source File Revision:

-

EA4 Static Analysis Compliance Guideline version:

1.04

Poly Space version:

2013b

TL109A sub project version:

2.3.0

Quality Check Items:

Rationale is required for all answers of No

tools/local folders' header files are appropriate and

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

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

N/A

Comments:

with conditional compilation, has Polyspace been run with all

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

(Note which conditional compilation results have been archived)

Codemetrics count OK

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

The dimension for the 2D array is flipped manually in Rte_Stubs.h

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

04/16/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 7: Integration Manual

Rev 2.01

21-Feb-18

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

Integration Manual Name:

ClsdLoopDampg_IntegrationManual.doc

Integration Manual Revision:

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:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

04/16/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

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

2 - Component Implementation

Component Implementation

Component Documentation

2.1 - ClsdLoopHys_IntegrationManual

Integration Manual

For

ClsdLoopHys

VERSION: 1.0

DATE: 10-MAY-2018

Prepared By:

Software Group,

Nexteer Automotive,

Tychy, Poland

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	Marek Brykczyński	1.0	10-May-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional Design Document

References

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

Sr. No.	Title	Version
1	EA4 Software Naming Conventions	1.02
2	Software Design and Coding Standards	2.01
3	SF073A_ClsdLoopHys_Design	See Synergy Sub Project Version

Dependencies

SWCs

Module	Required Feature
None

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

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

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 FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
ClsdLoopHysInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
ClsdLoopHysPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

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

N/A

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

2.2 - ClsdLoopHys_MDD

Module Design Document

For

ClsdLoopHys

July 17, 2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Tychy, Poland
Change History

Description

Author

Version

Date

Initial version

Marek Brykczyński

1

10-May-2018

Added: New input port and local function

Modified: the function Interpolate

Marek Brykczyński

2

17-July-2018

Table of Contents

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 ClsdLoopHys & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of ClsdLoopHys 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: ClsdLoopHysInit1 8

5.1.2 Per: ClsdLoopHysPer1 8

5.2 Server Runables 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 9

5.4.1 Interpolate 9

5.4.2 IntgtrLimCalcn 9

5.4.3 CompCalcn1 9

5.4.4 CompCalcn1 9

5.5 GLOBAL Function/Macro Definitions 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

The Module Design Document for SF073A_ClsdLoopHys_Impl.

Scope

The following definitions are used throughout this document:

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

ClsdLoopHys & High-Level Description

The Closed Loop Hysteresis function shall provide a controllable hysteresis shaped Reference Handwheel Torque component based on a current Rack Load.

Design details of software module

Graphical representation of ClsdLoopHys

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 FDD for local constants.

Software Component Implementation

Sub-Module Functions

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

Init: Init1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: Per1

Design Rationale

Refer FDD

Store Module Inputs to Local copies

Refer FDD

(Processing of function)………

Refer FDD

Store Local copy of outputs into Module Outputs

Refer FDD

Server Runables

None

Interrupt Functions

None

Module Internal (Local) Functions

Interpolate

Function Name	Interpolate	Type	Min	Max
Arguments Passed	Y_Tbl_1D: - ClsdLoopHysDelta - ClsdLoopHysGain - ClsdLoopHysRho*	Pointer to const table with uint16	0	10240 / 20480*
	VehSpd_Kph_T_u9p7	uint16	0	65408
Return Value	A result of a conversion of fixed-point to float32	float32	0	10 / 20*

IntgtrLimCalcn

Function Name	IntgtrLimCalcn	Type	Min	Max
Arguments Passed	HwVel_HwRadPerSec_T_f32	float32	-42	42
	HwAg_HwRad_T_f32	float32	-25.13274192	25.13274192
	UpprIngtrLim_Uls_T_f32	const pointer to float32	-5	5
	LwrIngtrLim_Uls_T_f32	const pointer to float32	-5	5
Return Value	-	-	-	-

CompCalcn1

Function Name	CompCalcn1	Type	Min	Max
Arguments Passed	HwVel_HwRadPerSec_T_f32	float32	-42	42
	HysBasFac_Uls_T_f32	float32	-10	10
	Delta_Uls_T_f32	float32	0	10
Return Value	Result_T_Uls_f32	Float32	-42000	42000

CompCalcn1

Function Name	CompCalcn2	Type	Min	Max
Arguments Passed	HwVel_HwRadPerSec_T_f32	float32	-42	42
	HysBasFac_Uls_T_f32	float32	-10	10
	Delta_Uls_T_f32	float32	0	10
Return Value	Result_T_Uls_f32	float32	-4200	37800

SysFricOffsLimdCalc

Function Name	SysFricOffsLimdCalc	Type	Min	Max
Arguments Passed	VehSpd_Kph_T_u9p7	uint16	0	65408
	SysFricOffs_HwNwtMtr_T_f32	float32	-5	5
Return Value	return value of conversion from u2p14 to float32	float32	0	2

Design Rationale

Refer FDD

Processing

Refer FDD

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

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

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.4.0 R4.0 Rev 3
2	MDD Guideline EA4	1.02
3	EA4 Software Naming Conventions	1.01
4	Software Design and Coding Standards	2.01
5	SF073A_ClsdLoopHys_Design	See Synergy Sub Project Version

2.3 - ClsdLoopHys_Review

Overview

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

Sheet 1: Cover Page

	Nexteer Automotive Confidential Proprietary Information Do Not Copy/Distribute Without Prior Permission


EA4 Nexteer SWC Implementation Peer Review Checklist
For
BMW FAAR WE














Prepared By:
Software Development Team
Nexteer Automotive
Tychy, Poland

EA4 Nexteer SWC Implementation Peer Review Checklist Version: 2.02 Date: 28-Jun-2018 © Nexteer Automotive

Sheet 2: Summary Sheet

Rev 2.02

27-Jun-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

ClsdLoopHys

Revision / Baseline:

SF073A_ClsdLoopHys_Design_2.0.0

Change Owner:

Marek Brykczyński

Work CR ID:

EA4#25676

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

Auto Code

Yes

Integration Manual

Yes

Davinci Files

N/A

SIL Testing

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

0.5

0

Component developer reviewers:

0.5

0

2

Other reviewers:

0

Total hours

1

0

2

Content reviewed

Lines of code:

changes

Elements of .arxml content:

changes

Pages of documentation:

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 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 3: Synergy Project

Rev 2.02

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

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

07/19/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 4: Davinci Files

Rev 2.02

27-Jun-18

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

N/A

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

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 "Write (explicit)"

Yes

Comments:

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

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

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

Per Instance Memory names and data types

Yes

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

07/19/18

Component Type :

Application

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Krzysztof Byrski

Comments:

Other Reviewer(s):

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

Sheet 5: Source Code

Rev 2.02

27-Jun-18

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

Source File Name:

ClsdLoopHys.c

Source File Revision:

2

Header File Name:

-

Header File Revision:

-

MDD Name:

ClsdLoopHys_MDD.docx

Revision:

2

SWC Design Name:

SF073A_ClsdLoopHys_Design

Revision:

2.0.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version:

EA4 Software Naming Convention followed:

Version:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

Yes

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

Yes

Comments:

from at least the changed areas of code

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

N/A

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

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

Yes

Comments:

is per standard

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

Yes

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

Yes

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

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

All code is mapped with SWC Design (all SWC

Yes

Comments:

Design subfunctions and/or model blocks identified

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

07/19/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Grzegorz Szafrański

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 6: MDD

Rev 2.02

27-Jun-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

ClsdLoopHys_MDD.docx

MDD Revision:

2

Source File Name:

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

Yes

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the SWC

Yes

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

07/19/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 7: PolySpace

Rev 2.02

27-Jun-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

ClsdLoopHys.c

Source File Revision:

2

Source File Name:

-

Source File Revision:

-

Source File Name:

-

Source File Revision:

-

EA4 Static Analysis Compliance Guideline version:

1.04

Poly Space version:

2013b

TL109A sub project version:

2.5.0

Quality Check Items:

Rationale is required for all answers of No

tools/local folders' header files are appropriate and

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

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

N/A

Comments:

with conditional compilation, has Polyspace been run with all

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

(Note which conditional compilation results have been archived)

Codemetrics count OK

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

MISRA AGC guidelines selected for Polyspace (N/A for hand

N/A

Comments:

coded components)

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

07/19/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 8: 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 9: Version History



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
2.02	Added a new tab for auto code as well as SIL testing Corrected some of the missing hyperlinks and formatting Added referencing for items under Reviewed in Summary Sheet tab	SW Engineering team	27-Jun-18	Lonnie Newton, Steven Horwath PCWG	28-Jun-18	Released

3 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD : 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.

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

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 CmplncErr & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of CmplncErr 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: CmplncErrInit1 8

5.1.2 Per: CmplncErrPer1 8

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

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

3.3 - CmplncErr_Review

Review_Checklist

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. 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

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

Yes

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

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

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

4 - Component Implementation

Component Implementation

Component Documentation

4.1 - CtrldVelRtn_ Peer Review Checklists

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. SF065A_CtrldVelRtn_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. SF065A_CtrldVelRtn_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. Ramachandran(Tata Elxsi)

Work CR ID:

EA4#14086

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:

Ramachandran(Tata Elxsi)

Review Date :

10/25/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

N/A

Comments:

versions (If available)

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

Initial Version

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Calibration port properties match DataDict.m

Yes

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

DataDict.m display variables: created as

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:

Ramachandran(Tata Elxsi )

Review Date :

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

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

CtrldVelRtn_MDD

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF065A_CtrldVelRtn_Design

Revision:

1.0.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version:2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

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

Yes

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

Comments:

including all use of fixed point macros and

There is no unintended overflow.

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

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Sheet 5: MDD

Rev 1.2

8-Jun-15

Peer Review Meeting Log (MDD Review)

MDD Name:

CtrldVelRtn_MDD

MDD Revision:

1

Source File Name:

CtrldVelRtn.c

Source File Revision:

1

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)

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:

Ramachandran(Tata Elxsi)

Review Date :

10/25/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

Sheet 6: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CtrldVelRtn.c

Source File Revision:

1

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

Ramachandran(Tata Elxsi)

Review Date :

10/25/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

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

Ramachandran(Tata Elxsi)

Review Date :

10/25/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Krishna Anne

4.2 - CtrldVelRtn_Integration Manual

Integration Manual

For

CtrldVelRtn

VERSION: 1.0

DATE: 17-OCT-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	TATA	1.0	17-Oct-2017

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD : SF065A_CtrldVelRtn_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

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
CtrldVelRtnInit1	None	RTE (Init)

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

4.3 - CtrldVelRtn_MDD

Module Design Document

For

CtrldVelRtn

OCT 17,2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

TATA

TRIVANDRUM, INDIA

Change History

Description	Author	Version	Date
Initial Version	TATA	1.0	17-Oct-2017

Table of Contents

1 Introduction 5

1.1 Purpose 5

2 CtrldVelRtn & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of CtrldVelRtn 7

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

3.2.2 Function level DFD 8

4 Constant Data Dictionary 9

4.1 Program (fixed) Constants 9

4.1.1 Embedded Constants 9

5 Software Component Implementation 10

5.1 Sub-Module Functions 10

5.1.1 Init: CtrldVelRtnInit1 10

5.1.1.1 Design Rationale 10

5.1.1.2 Module Outputs 10

5.1.2Per: CtrldVelRtnPer1 10

5.1.1.3 Design Rationale 10

5.1.1.4 Store Module Inputs to Local copies 10

5.1.1.5 (Processing of function)……… 10

5.1.1.6 Store Local copy of outputs into Module Outputs 10

5.2 Server Runables 10

5.3 Interrupt Functions 10

5.4 Module Internal (Local) Functions 11

5.4.1 Local Function #1 11

5.4.1.1 Design Rationale 11

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

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Appendix A Abbreviations and Acronyms 14

Appendix B Glossary 15

Appendix C References 16

Introduction

Purpose

MDD for Controlled Velocity Return.

CtrldVelRtn & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation of CtrldVelRtn

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
IDX2_CNT_U08	Uint8	CNT	2U
IDX3_CNT_U08	Uint8	CNT	3U
IDX4_CNT_U08	Uint8	CNT	4U
IDX5_CNT_U08	Uint8	CNT	5U

Software Component Implementation

Sub-Module Functions

5.1.1 Init: CtrldVelRtnInit1

Design Rationale

None

Module Outputs

None

5.1.2Per: CtrldVelRtnPer1

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	DrvrTqSeln	Type	Min	Max
Arguments Passed	MotTqCmdPwrLimd_MotNwtMtr_T_f32	float32	-8.8F	8.8F
	HwTq_HwNwtMtr_T_f32	float32	-10.0F	10.0F
	HwAgCmp_HwDeg_T_f32	float32	-1440.0F	1440.0F
	HwVel_HwRadPerSec_T_f32	float32	-42.0F	42.0F
	AssiMechPolarity_Uls_T_s08	sint8	-1U	1U
Return Value	DrvrTq_HwNwtMtr_T_f32	float32	-10.0F	10.0F

Design Rationale

None.

Processing

Refer to the “DriverTorque Selector” block of the Simulink model of the design.

Local Function #2

Function Name	Dampg	Type	Min	Max
Arguments Passed	HwVel_HwDegPerSec_T_f32	float32	-2406.0F	2406.0F
	CtrlSca_Uls_T_f32	float32	0.0F	1.0F
	VehSpd_Kph_T_u9p7	Uint16	0U	65535U
Return Value	DampgTerm_HwNwtMtr_T_f32	float32	-100.0F	100.0F

Design Rationale

None.

Processing

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

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 : SF065A_CtrldVelRtn_Design	See Synergy Sub-project version

5 - Component Implementation

Component Implementation

Component Documentation

5.1 - DutyCycThermProtn_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. SF009A_DutyCycThermProtn_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. SF009A_DutyCycThermProtn_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. Ramachandran(Tata Elxsi)

Work CR ID:

EA4#13255

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 changes were reviewed.

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

Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Ramachandran(Tata Elxsi)

Review Date :

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

Yes

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

All sender/receiver port read/writes using direct

Yes

Comments:

read/writes(List justification if not)

Runnable calling frequencies match FDD

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

General Notes / Comments:

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

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

DutyCycThermProtn_MDD.docx

Revision:

5

FDD/SCIR/DSR/FDR/CM Name:

SF009A_DutyCycThermProtn_Design

Revision:

4.0.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

N/A

Comments:

"magic numbers": [N12]

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

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,

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:

Ramachandran(Tata Elxsi)

Review Date :

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

DutyCycThermProtn_MDD.docx

MDD Revision:

5

Source File Name:

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

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:

No changes were made. Previous conditions are kept as is

General Notes / Comments:

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed 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/26/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:

DutyCycThermProtn.c

Source File Revision:

8

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

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

Lead Peer Reviewer:

Krishna Anne

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

5.3 - DutyCycThermProtn_MDD

Module Design Document

For

DutyCycThermProtn

Oct 26, 2017

Prepared By:

TATA ELXSI, TRIVANDRUM, INDIA

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

Table of Contents

1 DutyCycThermProtn & High-Level Description 5

2 Design details of software module 6

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

6 - Component Implementation

Component Implementation

Component Documentation

6.1 - Effort_IntegrationManual

Integration Manual

For

Effort

VERSION: 2.0

DATE: 7-MARCH-2018

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

Sl. No.

Description

Author

Version

Date

1

Initial version

Krzysztof Byrski

1.0

25-Jan-2018

2

Updated to add the include path present- sec 5.3

Updated sec 3.2 to explain the new Init function

Nimmy Mathews

2.0

7-Mar-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional Design Document

References

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

Sr. No.	Title	Version
1	EA4 Software Naming Conventions	1.0.3 draft
2	Software Design and Coding Standards	3.0 draft
3	SF068A_Effort_Design	See Synergy Sub Project Version

Dependencies

SWCs

Module	Required Feature
None

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

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

Note: There is a global Non-Rte function Effort_Init. This init function is generated by embedded coder and is not present in the Simulink model. This function is always empty and shall not be called. 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 FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
EffortInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
EffortPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
Effort_START_SEC_CODE	Code

* 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

6.2 - Effort_MDD

Module Design Document

For

Effort

May 9, 2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial version	Krzysztof Byrski	1	25-Jan-2018
Updated to add the additional _Init function generated for autocode in Section 5	Nimmy Mathews	2	7-Mar-2018
Added new input EffortCmdSca	Nimmy Mathews	3	9-May-2018

Table of Contents1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 Effort & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of Effort 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: EffortInit1 8

5.1.2 Init: Effort_Init 8

5.1.3 Per: EffortPer1 8

5.2 Server Runables 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 10

7 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 14

Introduction

Purpose

Module Design Document for SF068A_Effort_Impl.

Scope

The following definitions are used throughout this document:

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

Effort & High-Level Description

This function produces a handwheel reference torque for the closed loop system. The function should generate torque equal to the effort felt the driver on the handwheel. Output effort reference torque is a function of the Rack Force Estimated and Vehicle Speed.

Design details of software module

Graphical representation of Effort

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
HWTQCMDEFFORTHILIM_HWNWTMTR_F32	Single precision	HwNwtMtr	10
HWTQCMDEFFORTLOLIM_HWNWTMTR_F32	Single precision	HwNwtMtr	-10

Software Component Implementation

Sub-Module Functions

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

Init: EffortInit1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Init: Effort_Init

Design Rationale

_This init function is generated by embedded coder and is not present in the Simulink model.

This function is always empty and is not called.

Module Outputs

There are no outputs for this function.

Per: EffortPer1

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

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

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

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

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

6.3 - Effort_Review

Overview

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace
Integration Manual
help
Version History

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

Effort

Revision / Baseline:

SF068A_Effort_AGC_Impl_2.1.0

Change Owner:

Nimmy Mathews

Work CR ID:

EA4# 24063

Modified File Types:

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

Review Checklist Summary:

Reviewed:

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

N/A

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

All required reviewers participated

No

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

1

0

Component developer reviewers:

0

2

Other reviewers:

0

Total hours

1

0

2

Content reviewed

Lines of code:

2

Elements of .arxml content:

Pages of documentation:

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:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/22/18

Lead Peer Reviewer:

Avinash James

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:

Effort.c

Source File Revision:

4

Header File Name:

Effort.h

Header File Revision:

3

MDD Name:

Effort_MDD.docx

Revision:

3

SWC Design Name:

SF068A_Effort_Design

Revision:

2.1.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version:1.0.1

EA4 Software Naming Convention followed:

Version:1.0.3 draft

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.

Yes

Comments:

Synergy version matches change history

No

Comments:

and Version Control version in file comment block

Need new rules for autocoding

Change log contains detailed description of changes

No

Comments:

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

Need new rules for autocoding

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Verified using SIL testing

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

N/A

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

Yes

Comments:

All other includes are actually needed. (System includes

No

Comments:

only allowed in Nexteer library components)

Multiple inclusion for #include "NxtrFixdPt.h" in Effort.h file

Software Design and Coding Standards followed:

Version: 3.0 draft

Code comments are clear, correct, and adequate

N/A

Comments:

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

Comments are autogenerated.Need new rules for autocoding

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

Yes

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:

Multiple inclusion for #include "NxtrFixdPt.h" in Effort.h file. This is a bug reported to Mathworks. For timebeing we don’t have a solution to this. There will be no impact since there is inclusion protection in NxtrFixdPt.h file

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/22/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

Integrator and or
SW lead:

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:

Effort_MDD.docx

MDD Revision:

3

Source File Name:

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

N/A

Comments:

Change log contains detailed description of changes

N/A

Comments:

Changes Highlighted (for Unit Tester)

N/A

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:

No change required

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/22/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 5: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

Effort.c

Source File Revision:

4

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

2.0 draft

Poly Space version:

2013b

TL109A sub project version:

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

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/22/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: Integration Manual

Rev 2.01

21-Feb-18

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

Integration Manual Name:

Effort_IntegrationManual.doc

Integration Manual Revision:

2

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

N/A

Comments:

Latest template used

N/A

Comments:

Change log contains detailed description of changes

N/A

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

General Notes / Comments:

No change required to Integration manual

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/22/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

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

7 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD : 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

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

1 Introduction 4

1.1 Purpose 4

2 ElecPwrCns & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of ElecPwrCns 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 Per: ElecPwrCnsPer1 8

5.1.1.1 Design Rationale 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

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

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

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

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

N/A

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

N/A

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

N/A

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

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

8 - Component Implementation

Component Implementation

Component Documentation

8.1 - EotProtn_DesignReview

Overview

Summary Sheet
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. 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.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#15559

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:

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

Matthew Leser

Review Date :

09/25/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	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

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

1 EotProtn & High-Level Description 5

2 Design details of software module 6

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

9 - Component Implementation

Component Implementation

Component Documentation

9.1 - EpsStEstimn_IntegrationManual

Integration Manual

For

EpsStEstimn

VERSION: 1.0

DATE: April 12, 2018

Prepared By:

Matthew Leser,

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	Matthew Leser	1.0	12-Apr-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional Design Document

References

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

Sr. No.	Title	Version
1	FDD – SF066A_EpsStEstimn_Design	See Synergy subproject version
2	Software Naming Conventions	Process 04.02.00
3	Software Coding Standards	Process 04.02.00

Dependencies

SWCs

Module	Required Feature
None

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

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

None

Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
None

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Refer DataDict.m file

Required Global Data Outputs

Refer DataDict.m file

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
EpsStEstimnInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
EpsStEstimnPer1	None	RTE (2 ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
EpsStEstimn_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None.

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None.

9.2 - EpsStEstimn_MDD

Module Design Document

For

EpsStEstimn

April 12, 2018

Prepared By:

Matthew Leser

Software Group,

Nexteer Automotive,

Saginaw, MI, USAChange History

Description	Author	Version	Date
Initial Version	Matthew Leser	1.0	12-Apr-2018

Table of Contents

1 Introduction 4

1.1 Purpose 4

2 EpsStEstimn & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of EpsStEstimn 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: EpsStEstimnInit1 8

5.1.1.1 Design Rationale 8

5.1.1.2 Module Outputs 8

5.1.2 Per: EpsStEstimnPer1 8

5.1.2.1 Design Rationale 8

5.1.2.2 Store Module Inputs to Local copies 8

5.1.2.3 (Processing of function)……… 8

5.1.2.4 Store Local copy of outputs into Module Outputs 8

5.2 Server Runables 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 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

Introduction

Purpose

Module design document for EpsStEstimn.

EpsStEstimn & High-Level Description

Design details of software module

Graphical representation of EpsStEstimn

Data Flow Diagram

Component level DFD

N/A

Function level DFD

N/A

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
NA	NA	NA	NA

Refer to .m file for other defined constants.

Software Component Implementation

Sub-Module Functions

Init: EpsStEstimnInit1

Design Rationale

Module Outputs

Refer to FDD

Per: EpsStEstimnPer1

Design Rationale

None

Store Module Inputs to Local copies

Refer to FDD

(Processing of function)………

Refer to FDD

Store Local copy of outputs into Module Outputs

Refer to FDD

Server Runnables

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
DFD	Design functional diagram
MDD	Module design Document

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

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

9.3 - EpsStEstimn_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Source Code
PolySpace
help
Version History

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

EpsStEstimn

Revision / Baseline:

SF066A_EpsStEstimn_Impl_2.1.0

Change Owner:

Shawn Penning

Work CR ID:

EA4#23204

Modified File Types:

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

Review Checklist Summary:

Reviewed:

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

N/A

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

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

Component developer reviewers:

0

0.5

0

2

Other reviewers:

0

0.5

0

Total hours

0.5

1

Content reviewed

Lines of code:

30

Elements of .arxml content:

0

Pages of documentation:

0

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

Each peer review shall start with a clean copy of the latest peer review checklist template. Save in the doc folder of the component implementation, with the file name in the format SWCShortName_Review.xlsx. If the existing review in Synergy has a different name, the name must be changed IN SYNERGY (rather than by syncing in a new file with the new name) so that the file history will be properly maintained.

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

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

Sheet 2: Synergy Project

Rev 2.01

21-Feb-18

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

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

Yes

Comments:

File/folder structure is correct per documentation in

Yes

Comments:

TL109A_SwcSuprt

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

05/04/18

Lead Peer Reviewer:

Avinash James

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:

EpsStEstimn.c

Source File Revision:

2

Header File Name:

Header File Revision:

MDD Name:

EpsStEstimn_MDD.docx

Revision:

1

SWC Design Name:

SF066A_EpsStEstimn_Design

Revision:

1

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

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:

Synergy version matches change history

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

Yes

Comments:

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

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

N/A

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

N/A

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All 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

N/A

Comments:

defined in the SWC Design DataDict.m file : [N53]

All code is mapped with SWC Design (all SWC

N/A

Comments:

Design subfunctions and/or model blocks identified

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

05/04/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Akilan

Comments:

KPIT did design however Fei filled as designer reviewer. Approved by Steve Horwath.

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 4: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

EpsStEstimn.c

Source File Revision:

2

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

No

Comments:

Path Count is 324, above the 300 threshold.

for all functions in the component per Design

Due to time constraints, path count will not be fixed until next version.

and Coding Standards rule [N47]

General Notes / Comments:

Rte_Stubs.h was hand modified for Polyspace. The reason being that TL109A does not understand how to interpret an output that is a structure type.

Polyspace flags writing to the elements of the output structure'TorsBarStEstimd_Uls_T_rec'. This is because polyspace does not understand that the output is a structure. There is no legitimate issue here as this is an issue with polyspace understanding this variable. - Approved by Steven Horwath 4/18/2018

Review Board:

Change Owner:

Shawn Penning

Review Date :

05/04/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Steve Horwath

Sheet 5: 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 6: Version History



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










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

Component Implementation

Component Documentation

10.1 - FalbckAssi_IntegrationManual

Integration Manual

For

FalbckAssi

VERSION: 1.0

DATE: 16-APR-2018

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Krzysztof Byrski	1.0	16-Apr-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional Design Document

References

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

Sr. No.	Title	Version
1	EA4 Software Naming Conventions	1.02
2	Software Design and Coding Standards	2.01
3	SF111A_FalbckAssi_Design	See Synergy Sub Project Version

Dependencies

SWCs

Module	Required Feature
None

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

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

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 FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
FalbckAssiInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
FalbckAssiPer1	None	RTE(2ms)

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

10.2 - FalbckAssi_MDD

Module Design Document

For

FalbckAssi

April 19, 2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial version	Krzysztof Byrski	1	18-Oct-2017

Table of Contents

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 FalbckAssi & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of FalbckAssi 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: FalbckAssiInit1 8

5.1.2 Per: FalbckAssiPer1 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

Module Design Document for SF111A_FalbckAssi_Impl.

Scope

The following definitions are used throughout this document:

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

FalbckAssi & High-Level Description

Fallback Assist shall provide assist motor torque command in a situation when system detects fault of a main motor torque generation functionality

Design details of software module

Graphical representation of FalbckAssi

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 FDD for local constants

Software Component Implementation

Sub-Module Functions

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

Init: FalbckAssiInit1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: FalbckAssiPer1

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

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

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

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.4.0 R4.0 Rev 3
2	MDD Guideline EA4	1.02
3	EA4 Software Naming Conventions	1.01
4	Software Design and Coding Standards	2.01
5	SF111A_FalbckAssi_Design	See Synergy Sub Project Version

10.3 - FalbckAssi_Review

Overview

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

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

FalbckAssi

Revision / Baseline:

SF111A_FalbckAssi_Impl_1.0.0

Change Owner:

Krzysztof Byrski

Work CR ID:

EA4#22536

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

Yes

Integration Manual

Yes

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

0.5

0

Component developer reviewers:

0

0.5

0

1.5

Other reviewers:

0

0.5

0

Total hours

0.5

1.5

0

2

Content reviewed

Lines of code:

All

Elements of .arxml content:

All

Pages of documentation:

All

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:

Review Board:

Change Owner:

Krzysztof Byrski

Review Date :

04/20/2018

Lead Peer Reviewer:

Marek Brykczyński

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Davinci Files

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

N/A

Comments:

versions (If available) and changes match changes

Initial version

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

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 "Write (explicit)"

Yes

Comments:

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

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

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

Per Instance Memory names and data types

Yes

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Krzysztof Byrski

Review Date :

04/20/2018

Component Type :

Application

Lead Peer Reviewer:

Marek Brykczyński

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Integrator was unavailable

Other Reviewer(s):

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

Sheet 4: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

FalbckAssi.c

Source File Revision:

1

Header File Name:

-

Header File Revision:

-

MDD Name:

FalbckAssi_MDD.docx

Revision:

1

SWC Design Name:

SF111A_FalbckAssi_Design

Revision:

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 01.01

EA4 Software Naming Convention followed:

Version: 1.02

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

Yes

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

Initial version

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

N/A

Comments:

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

Initial version

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

N/A

Comments:

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

Initial version

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

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

Yes

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

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

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Krzysztof Byrski

Review Date :

04/20/2018

Lead Peer Reviewer:

Marek Brykczyński

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

Wojciech Janusz

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 5: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

FalbckAssi_MDD.docx

MDD Revision:

1

Source File Name:

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

N/A

Comments:

Initial version

Changes Highlighted (for Unit Tester)

N/A

Comments:

Initial version

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

Yes

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the SWC

Yes

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Krzysztof Byrski

Review Date :

04/20/2018

Lead Peer Reviewer:

Marek Brykczyński

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

FalbckAssi.c

Source File Revision:

1

Source File Name:

-

Source File Revision:

-

Source File Name:

-

Source File Revision:

-

EA4 Static Analysis Compliance Guideline version:

1.04

Poly Space version:

2013b

TL109A sub project version:

2.3.0

Quality Check Items:

Rationale is required for all answers of No

tools/local folders' header files are appropriate and

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Initial version

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

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

N/A

Comments:

with conditional compilation, has Polyspace been run with all

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

(Note which conditional compilation results have been archived)

Codemetrics count OK

Yes

Comments:

for all functions in the component per Design

Cyclomatic complexity: 1, static path: 1.

and Coding Standards rule [N47]

General Notes / Comments:

Review Board:

Change Owner:

Krzysztof Byrski

Review Date :

04/20/2018

Lead Peer Reviewer:

Marek Brykczyński

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 7: Integration Manual

Rev 2.01

21-Feb-18

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

Integration Manual Name:

FalbckAssi_IntegrationManual.doc

Integration Manual Revision:

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

N/A

Comments:

Initial version

Changes Highlighted (for Integrator)

N/A

Comments:

Initial version

General Notes / Comments:

Review Board:

Change Owner:

Krzysztof Byrski

Review Date :

04/20/2018

Lead Peer Reviewer:

Marek Brykczyński

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Integrator was unavailable

Other Reviewer(s):

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

Sheet 8: 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 9: Version History



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










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

11 - Component Implementation

Component Implementation

Component Documentation

11.1 - GlbLimr_IntegrationManual

Integration Manual

For

GlbLimr

VERSION: 1.0

DATE: 20-APR-2018

Prepared By:

Software Group,

Nexteer Automotive,

Tychy, Poland

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	Marek Brykczyński	1.0	20-Apr-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional Design Document

References

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

Sr. No.	Title	Version
1	EA4 Software Naming Conventions	1.02
2	Software Design and Coding Standards	2.01
3	CF082A_GlbLimr_Design	See Synergy Sub Project Version

Dependencies

SWCs

Module	Required Feature
None

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

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

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 FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
GlbLimrInit1	None	RTE (Init)

Runnable	Scheduling Requirements	Trigger
GlbLimrPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
GlbLimr_START_SEC_CODE	Code

* 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

11.2 - GlbLimr_MDD

Module Design Document

For

GlbLimr

April 20, 2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Tychy, Poland
Change History

Description	Author	Version	Date
Initial version	Marek Brykczyński	1	20-Apr-2018

Table of Contents

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 GlbLimr & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of GlbLimr 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: GlbLimr_Init1 8

5.1.2 Per: GlbLimr_Per1 8

5.2 Server Runnables 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 9

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

MDD for SF110A_GlbLimr_Impl.

Scope

The following definitions are used throughout this document:

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

GlbLimr & High-Level Description

The Global Limiter software component defines safe operating conditions and applies limits to a motor torque command based on these conditions.

Design details of software module

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

Graphical representation of GlbLimr

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
D_NUMLOOPS_CNT	1	Cnt	2

Software Component Implementation

Sub-Module Functions

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

Init: GlbLimr_Init1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: GlbLimr_Per1

Design Rationale

Refer FDD

Store Module Inputs to Local copies

Refer FDD

(Processing of function)………

Refer FDD

Store Local copy of outputs into Module Outputs

Refer FDD

Server Runnables

None

Interrupt Functions

None

Module Internal (Local) Functions

GlbLimrCompensator

Function Name	GlbLimrCompensator	Type	Min	Max
Arguments Passed	Assist_MotNwtMtr_T_f32	float32	-8.8	8.8
	GlbLimrNotchNumberFil1_Uls_T_f32	float32	-1000000000	1000000000
	GlbLimrNotchNumberFil2_Uls_T_f32	float32	-1000000000	1000000000
Return Value	CompAssist_MotNwtMtr_T_f32	float32	-8.8	8.8

Design Rationale

Refer FDD

Processing

Refer FDD

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

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

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

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

11.3 - GlbLimr_Review

Overview

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

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

GlbLimr

Revision / Baseline:

SF110A_GlbLimr_Impl_1.0.0

Change Owner:

Marek Brykczyński

Work CR ID:

EA4#22473

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

Yes

Integration Manual

Yes

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

0.5

0

Component developer reviewers:

0.5

0

2

Other reviewers:

0

Total hours

1

0

2

Content reviewed

Lines of code:

all

Elements of .arxml content:

all

Pages of documentation:

all

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:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/20/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Davinci Files

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

Yes

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

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 "Write (explicit)"

Yes

Comments:

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

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

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

Per Instance Memory names and data types

Yes

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/20/18

Component Type :

Application

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

Sheet 4: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

GlbLimr.c

Source File Revision:

1

Header File Name:

-

Header File Revision:

-

MDD Name:

GlbLimr_MDD.docx

Revision:

1

SWC Design Name:

SF110A_GlbLimr_Design

Revision:

1.0.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version:

EA4 Software Naming Convention followed:

Version:

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

Verified no possibility of uninitialized variables being

Yes

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All access of motor control loop data uses macros

N/A

Comments:

generated by the motor control manager

All loops have termination conditions that ensure

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

All code is mapped with SWC Design (all SWC

Yes

Comments:

Design subfunctions and/or model blocks identified

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/20/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Wojciech Janusz

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 5: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

GlbLimr_MDD.docx

MDD Revision:

1

Source File Name:

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

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

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/20/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

GlbLimr.c

Source File Revision:

1

Source File Name:

-

Source File Revision:

-

Source File Name:

-

Source File Revision:

-

EA4 Static Analysis Compliance Guideline version:

1.04

Poly Space version:

2013b

TL109A sub project version:

2.4.0

Quality Check Items:

Rationale is required for all answers of No

tools/local folders' header files are appropriate and

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

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

Yes

Comments:

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:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/20/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

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

12 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	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

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

1 Introduction 5

1.1 Purpose 5

2 HiLoadStallLimr & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of HiLoadStallLimr 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: HiLoadStallLimrInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: HiLoadStallLimrPer1 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runables 9

5.3 Interrupt Functions 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

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

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

12.3 - HiLoadStallLimr_Review

Overview

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace
help
Version History

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

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:

Review Board:

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

Revision:

4

SWC Design Name:

SF017A_HiLoadStallLimr_Design

Revision:

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:

Synergy version matches change history

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

Yes

Comments:

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

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

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:

Review Board:

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:

Review Board:

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:

Review Board:

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

13 - Component Implementation

Component Implementation

Component Documentation

13.1 - HwRefTqSum_IntegrationManual

Integration Manual

For

HwRefTqSum

VERSION: 2.0

DATE: 7-Mar-2018

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

TATA

1.0

02/12/2018

2

Updated to add the include path present- sec 5.3

Updated sec 3.2 to explain the new Init function

Nimmy Mathews

2.0

7-Mar-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design Functional Diagram
MDD	Module Design Document
FDD	Functional Design Document

References

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

Sr. No.	Title	Version
1	FDD: SF069A_HwRefTqSum_Design_1.0.0	See synergy sub project version
2	Software Naming Conventions	1.0.3 draft
3	Software Coding Standards	3.0 draft

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

Note: There is a global Non-Rte function HwRefTqSum_Init. This init function is generated by embedded coder and is not present in the Simulink model. This function is always empty and shall not be called. Configuration REQUIREMeNTS

Build Time Config

Modules	Notes
None	N/A

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None	N/A

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None			N/A

Manual Configuration Changes

Constant	Notes	SWC
None	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
HwRefTqSumInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
HwRefTqSumPer1	None	RTE (2ms)

Srv Runnable	Scheduling Requirements	Trigger
None	None	None

Srv Runnable	Scheduling Requirements	Trigger
None	None	None

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
HwRefTqSum_START_SEC_CODE	Code

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

Non RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

RTE NvM Blocks

Block Name

None

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

13.2 - HwRefTqSum_MDD

Module Design Document

For

HwRefTqSum

March 7, 2018Feb 12, 2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Sl. No.	Description	Author	Version	Date
1	Initial Version	TATA	1.0	12-Feb-2018
2	Updated to add the additional _Init function generated for autocode in Section 5	Nimmy Mathews	2	7-Mar-2018

Table of Contents

1 Introduction 4

1.1 Purpose 4

2 HwRefTqSum & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of HwRefTqSum 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: HwRefTqSumInit1 8

5.1.2 Init: HwRefTqSum_Init 8

5.1.3 Per: HwRefTqSumPer1 8

5.2 Server Runnables 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 10

7 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 14

Introduction

Purpose

MDD for HwRefTqSum

HwRefTqSum & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation of HwRefTqSum

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

Init: HwRefTqSumInit1

Design Rationale

None

Module Outputs

None

Init: HwRefTqSum_Init

Design Rationale

_This init function is generated by embedded coder and is not present in the Simulink model.

This function is always empty and is not called.

Module Outputs

There are no outputs for this function.

Per: HwRefTqSumPer1

Design Rationale

None

Store Module Inputs to Local copies

None

Processing of function

None

Store Local copy of outputs into Module Outputs

None

Server Runnables

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.4.0 R4.0 Rev 3
2	MDD Guideline	1.02
3	Software Naming Conventions.doc	1.0.3 draft
4	Software Design and Coding Standards.doc	3.0 draft
5	FDD: SF069A_HwRefTqSum_Design_1.0.1	See Synergy sub project version

13.3 - HwRefTqSum_Review

Overview

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace
Integration Manual
help
Version History

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

HwRefTqSum

Revision / Baseline:

SF069A_HwRefTqSum_AGC_Impl_1.1.0

Change Owner:

Nimmy Mathews

Work CR ID:

EA4#20880

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

Yes

Integration Manual

Yes

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

1

0

Component developer reviewers:

0

2

0

4

Other reviewers:

0

1

0

Total hours

1

4

0

5

Content reviewed

Lines of code:

25

Elements of .arxml content:

Pages of documentation:

4

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:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/09/18

Lead Peer Reviewer:

Matthew Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Siva

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:

HwRefTqSum.c

Source File Revision:

2

Header File Name:

HwRefTqSum.h

Header File Revision:

1

MDD Name:

HwRefTqSum_MDD.doc

Revision:

2

SWC Design Name:

SF069A_HwRefTqSum_Design

Revision:

1.0.1

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version:1.0.1

EA4 Software Naming Convention followed:

Version:1.0.3 draft

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

Yes

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

No

Comments:

and Version Control version in file comment block

Need new rules for autocoding

Change log contains detailed description of changes

No

Comments:

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

Need new rules for autocoding

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Verified using SIL testing

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

N/A

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

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

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

No

Comments:

contain correct information: [N43]

Need new rules for autocoding

Code formatting (indentation, placement of

Yes

Comments:

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

As per the draft version 3.0

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All access of motor control loop data uses macros

N/A

Comments:

generated by the motor control manager

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

N/A

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

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

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/09/18

Lead Peer Reviewer:

Matthew Leser

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Nimmy Mathews

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

Siva, Shawn Penning

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

Steven Horwath

Sheet 4: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

HwRefTqSum_MDD.doc

MDD Revision:

2

Source File Name:

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

No change for this version

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:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/09/18

Lead Peer Reviewer:

Matthew Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

siva

Shawn Penning

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:

HwRefTqSum.c

Source File Revision:

2

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

2.0 draft

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:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/09/18

Lead Peer Reviewer:

Matthew Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Siva

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

Sheet 6: Integration Manual

Rev 2.01

21-Feb-18

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

Integration Manual Name:

HwRefTqSum_IntegrationManual.doc

Integration Manual Revision:

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:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/09/18

Lead Peer Reviewer:

Matthew Leser

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Kevin Smith

Comments:

Other Reviewer(s):

Siva

Shawn Penning

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

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

14 - Component Implementation

Component Implementation

Component Documentation

14.1 - HwTqTrakgCtrl_IntegrationManual

Integration Manual

For

HwTqTrakgCtrl

VERSION: 1.0

DATE: 7-MARCH-2018

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	Nimmy Mathews	1.0	7-Mar-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 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
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	EA4 Software Naming Conventions	1.0.3 draft
2	Software Design and Coding Standards	3.0 draft
3	SF070A_HwTqTrakgCtrl_Design	See Synergy Sub Project Version

Dependencies

SWCs

Module	Required Feature
None

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

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

Note: There is a global Non-Rte function HwTqTrakgCtrl_Init. This init function is generated by embedded coder and is not present in the Simulink model. This function is always empty and shall not be called.

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 FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
HwTqTrakgCtrlInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
HwTqTrakgCtrlPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
HwTqTrakgCtrl_START_SEC_CODE	Code

* 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

14.2 - HwTqTrakgCtrl_MDD

Module Design Document

For

HwTqTrakgCtrl

May 9, 2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial version	Nimmy Mathews	1	7-Mar-2018
Added new input MotTqCmdOvrl	Nimmy Mathews	2	9-May-2018

Table of Contents

2 HwTqTrakgCtrl High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of HwTqTrakgCtrl 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: HwTqTrakgCtrlInit1 8

5.1.2 Init: HwTqTrakgCtrl_Init 8

5.1.3 Per: HwTqTrakgCtrlPer1 8

5.2 Server Runnables 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 10

7 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 14

Introduction

Purpose

Module Design Document for SF070A_HwTqTrakgCtrl_Impl.

Scope

The following definitions are used throughout this document:

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

HwTqTrakgCtrl High-Level Description

This component is used to calculate motor torque command from estimate, torsion bar states, handwheel torque command and tracking control gains.

Design details of software module

Graphical representation of HwTqTrakgCtrl

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
SYSTQRATMAXVAL_HWNWTMTRPERMOTNWTMTR_F32	Single precision	HwNwtMtrPerMotNwtMtr	50
SYSTQRATMINVAL_HWNWTMTRPERMOTNWTMTR_F32	Single precision	HwNwtMtrPerMotNwtMtr	10

Software Component Implementation

Sub-Module Functions

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

Init: HwTqTrakgCtrlInit1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Init: HwTqTrakgCtrl_Init

Design Rationale

This init function is generated by embedded coder and is not present in the Simulink model.

This function is always empty and is not called.

Module Outputs

There are no outputs for this function.

Per: HwTqTrakgCtrlPer1

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

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

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

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

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

14.3 - HwTqTrakgCtrl_Review

Overview

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

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

HwTqTrakgCtrl

Revision / Baseline:

SF070A_HwTqTrakgCtrl_AGC_Impl_2.0.0

Change Owner:

Nimmy Mathews

Work CR ID:

EA4#21439

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

Yes

Integration Manual

Yes

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

1

Component developer reviewers:

0

3

Other reviewers:

0

Total hours

1

0

1

2

Content reviewed

Lines of code:

10

Elements of .arxml content:

8

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:

Waiting for baseline

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

Remove unused file from tools folder - Component.dzvc93.silent.dcusr

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/14/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Davinci Files

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

Yes

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

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 "Write (explicit)"

Yes

Comments:

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

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

Yes

Comments:

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

Per Instance Memory names and data types

N/A

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/14/18

Component Type :

Application

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

Sheet 4: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

HwTqTrakgCtrl.c

Source File Revision:

2

Header File Name:

HwTqTrakgCtrl.h

Header File Revision:

2

MDD Name:

HwTqTrakgCtrl_MDD.docx

Revision:

2

SWC Design Name:

SF070A_HwTqTrakgCtrl_Design

Revision:

2.0.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version:1.0.1

EA4 Software Naming Convention followed:

Version:1.0.3 draft

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

Yes

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

No

Comments:

and Version Control version in file comment block

Need new rules for autocoding

Change log contains detailed description of changes

No

Comments:

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

Need new rules for autocoding

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Verified using SIL testing

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

N/A

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

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

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

No

Comments:

contain correct information: [N43]

Need new rules for autocoding

Code formatting (indentation, placement of

Yes

Comments:

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

As per the draft version 3.0

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

Yes

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

Yes

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

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

Yes

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:

Complexity in understanding the code- Better to break up the code to multiple lines

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/14/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 5: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

HwTqTrakgCtrl_MDD.doc

MDD Revision:

2

Source File Name:

HwTqTrakgCtrl.c

Source File Revision:

2

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the 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:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/14/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

HwTqTrakgCtrl.c

Source File Revision:

2

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

2.0 draft

Poly Space version:

2013b

TL109A sub project version:

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

Polypsace Compilation Error: The prototype for Rte_Read_TorsBarStEstimd_Rec is not available in the Rte_Stubs.h file due to TL109 limitation to support input structure will cause compilation error. The Rte_Read_TorsBarStEstimd_Val in the Rte_Stubs.h has been manually changed to Rte_Read_TorsBarStEstimd_Rec to resolve this issue

Polypsace Overflow Warning: Polsypace gives overflow warning for the structure elements since DRS doesn’t include the min/max for the structure elements due to the limitation of TL109 to support input structure. Hence the min/max of the structure elements are added manually to DRS to remove this overflow warning.

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

05/14/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

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

15 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
<1>	<MDD Guidelines>	Process 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

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

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 InertiaCmpVel & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of InertiaCmpVel 6

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

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

Appendix A Abbreviations and Acronyms 14

Appendix B Glossary 15

Appendix C References 16

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

15.3 - InertiaCmpVel_PeerReview

Overview

Summary Sheet
Synergy Project
Source Code
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

InertiaCmpVel

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

SF014A_IntertiaCmpVel_Impl_1.13.0

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

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

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

02/06/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Source Code

Rev 2.00

29-Nov-17

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

Source File Name:

InertiaCmpVel.c

Source File Revision:

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

Header File Name:

Header File Revision:

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

MDD Name:

InertiaCmpVel_MDD.docx

Revision:

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

SWC Design Name:

SF014A_InertiaCmpVel_Design

Revision:

Windows User: Intended Use: For FDDs, list the Synergy baseline number (just the number part of the Synergy baseline name) of the FDD baseline being implemented. E.g., for SF001A_Assi_Design_1.3.1, this field would say "1.3.1" 1.16.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.01.00

for variable names

N/A

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

N/A

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

N/A

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document or Model)

Yes

Comments:

in all areas where code was changed and/or Simulink

model was color-coded as changed and/or mentioned

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

layers of Simulink model for possible color coding not

reflected at a higher level, and includes looking at any

intermediate SWC Design versions between the version being

implemented and the version that was included as a

subproject in the previous implementation.)

Code comparison against previous version matches

Yes

Comments:

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

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

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

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Windows User: Intended Use: list version/revision of latest released Software Design and Coding Standards document. Version: 2.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 access of motor control loop data uses macros

N/A

Comments:

generated by the motor control manager

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

N/A

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

N/A

Comments:

defined in the SWC Design DataDict.m file : [N53]

All code is mapped with SWC Design (all SWC

Yes

Comments:

Design subfunctions and/or model blocks identified

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Matthew Leser

Review Date :

02/06/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Fei Yuan

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 4: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

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

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 :

02/06/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

16 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	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

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

1 LimrCdng High-Level Description 4

2 Design details of software module 5

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

5 Known Limitations with Design 8

6 UNIT TEST CONSIDERATION 9

Appendix A Abbreviations and Acronyms 10

Appendix B Glossary 11

Appendix C References 12

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

16.3 - LimrCdng_PeerReview

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. 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

Working EA4 Software Naming Convention followed:

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

17 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD : 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

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

1.1 Purpose 5

2 LoaMgr High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of LoaMgr 7

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

3.2.2 Function level DFD 8

4 Constant Data Dictionary 9

4.1 Program (fixed) Constants 9

4.1.1 Embedded Constants 9

5 Software Component Implementation 10

5.1 Sub-Module Functions 10

5.1.1 Init: 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 Module Internal (Local) 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

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

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

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

18 - Component Implementation

Component Implementation

Component Documentation

18.1 - LrndRackCentr_IntegrationManual

Integration Manual

For

LrndRackCentr

VERSION: 1.0

DATE: 27-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	ML	1.0	27-Oct-2017

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 Dependencies 7

3.1 SWCs 7

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

4 Configuration REQUIREMeNTS 8

4.1 Build Time Config 8

4.2 Configuration Files to be provided by Integration Project 8

4.3 Da Vinci Parameter Configuration Changes 8

4.4 DaVinci Interrupt Configuration Changes 8

4.5 Manual Configuration Changes 8

5 Integration DATAFLOW REQUIREMENTS 9

5.1 Required Global Data Inputs 9

5.2 Required Global Data Outputs 9

5.3 Specific Include Path present 9

6 Runnable Scheduling 10

7 Memory Map REQUIREMENTS 11

7.1 Mapping 11

7.2 Usage 11

7.3 NvM Blocks 11

8 Compiler Settings 12

8.1 Preprocessor MACRO 12

8.2 Optimization Settings 12

9 Appendix 13

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
<1>	<MDD Guidelines>	Process 04.02.00
<2>	<Software Naming Conventions>	Process 04.02.00
<3>	<Coding standards>	Process 04.02.00
<4>	FDD – SF039A_LrndRackCentr_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

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

None

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
LrndRackCentrInit1	None	RTE Init

Runnable	Scheduling Requirements	Trigger
LrndRackCentrPer1	None	4 ms
RstRackCentrMotAg	None	On Event
RstRackCentrMotRev	None	On Event

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None
LrndRackCentr_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

Refer to FDD

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

18.2 - LrndRackCentr_MDD

Module Design Document

For

LrndRackCentr

October 26, 2017

Prepared By:

Matthew Leser,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	ML	1.0	26-Oct-2017

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 LrndRackCenter & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of LrndRackCentr 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: LrndRackCentrInit1 9

5.1.1.1 Design Rationale 9

5.1.2 Per: LrndRackCentrPer1 9

5.1.2.1 Design Rationale 9

5.2 Server Runnable 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 9

5.4.1 Local Function #1 9

5.4.1.1 Description 9

5.4.2 Local Function #2 9

5.4.2.1 Description 10

5.5 GLOBAL Function/Macro Definitions 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

Scope

LrndRackCenter & High-Level Description

Refer FDD.

Design details of software module

Graphical representation of LrndRackCentr

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 DataDict.m file from FDD for other constants	-	-	-

Software Component Implementation

Sub-Module Functions

Init: LrndRackCentrInit1

Refer FDD Simulink model

Design Rationale

None

Per: LrndRackCentrPer1

Refer FDD Simulink Model

Design Rationale

Refer to Anomaly EA4#17201. Implementation deviates from design to fix for build.

Server Runnable

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	ManLrnRackCentr	Type	Min	Max
Arguments Passed	HwAg_HwDeg_T_f32	float32	-1440	1440
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350	1350
	MotTqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
Return Value	None

Description

Implementation of ‘MANUAL LEARN RACK CENTER’ subsystem.

Local Function #2

Function Name	ChkRackCentr	Type	Min	Max
Arguments Passed	HwTrvl_HwDeg_T_f32	float32	0	2880
	RackCentr_HwDeg_T_f32	float32	-1440	1440
	*RackCentrMotAgVld_Cnt_T_logl	boolean	FALSE	TRUE
	*RackCentrCmpl_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	None

Description

Implementation of ‘Confirm Rack Center Found’ subsystem.

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

Refer to Anomaly EA4#17201. Implementation deviates from design to fix for build.

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

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

18.3 - LrndRackCentr_PeerReviewChecklist

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. SF039A_LrndRackCentr_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. SF039A_LrndRackCentr_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#14383

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:

Refer to Anomaly EA4#17201. Implementation deviates from design to fix for build.

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

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Yes

Comments:

For components not using application data types, do all

Yes

Comments:

port interface names end in PortIf and a sequence number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

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

N/A

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header(s) file correctly

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

All changed files have been compared against previous

N/A

Comments:

versions (If available)

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

Initial Version

Automated validation check is performed

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m

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 :

11/07/17

Component Type :

Application

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Shawn Penning

Sheet 4: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

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

LrndRackCentr_MDD.docx

Revision:

1

FDD/SCIR/DSR/FDR/CM Name:

SF039A_LrndRackCentr_Design

Revision:

1.0.0/2.0.0

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

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

Yes

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

Yes

Comments:

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

All code is mapped with FDD (all FDD

Yes

Comments:

subfunctions and/or model blocks identified

with code comments; all code corresponds to

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

Review did not identify violations of other

Yes

Comments:

coding standard rules

Anomaly or Design Work CR created

Yes

Comments: List Anomaly or CR numbers

for any FDD corrections needed

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

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

LrndRackCentr_MDD.docx

MDD Revision:

1

Source File Name:

LrndRackCentr.c

Source File Revision:

1

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

N/A

Comments:

Initial Version

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the FDD are

N/A

Comments:

noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

11/07/17

Lead Peer Reviewer:

Avinash James

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

Integration Manual Revision:

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

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

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 :

11/07/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

LrndRackCentr.c

Source File Revision:

1

EA4 Static Analysis Compliance Guideline version:

01.03.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

Quality Check Items:

Rationale is required for all answers of No

Contract Folder's header files are appropriate and

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

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

N/A

Comments:

comments still appropriate

Initial Version

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

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

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

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

Change Owner:

Matthew Leser

Review Date :

11/07/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

19 - Component Implementation

Component Implementation

Component Documentation

19.1 - LrnPinionCentr_IntegrationManual

Integration Manual

For

LrnPinionCentr

VERSION: 1.0

DATE: 18-Sep-2017

Prepared By:

Matthew Leser,

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	ML	1.0	18-Sep-2017

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 Dependencies 7

3.1 SWCs 7

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

4 Configuration REQUIREMeNTS 8

4.1 Build Time Config 8

4.2 Configuration Files to be provided by Integration Project 8

4.3 Da Vinci Parameter Configuration Changes 8

4.4 DaVinci Interrupt Configuration Changes 8

4.5 Manual Configuration Changes 8

5 Integration DATAFLOW REQUIREMENTS 9

5.1 Required Global Data Inputs 9

5.2 Required Global Data Outputs 9

5.3 Specific Include Path present 9

6 Runnable Scheduling 10

7 Memory Map REQUIREMENTS 11

7.1 Mapping 11

7.2 Usage 11

7.3 NvM Blocks 11

8 Compiler Settings 12

8.1 Preprocessor MACRO 12

8.2 Optimization Settings 12

9 Appendix 13

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
<1>	<MDD Guidelines>	Process 04.02.00
<2>	<Software Naming Conventions>	Process 04.02.00
<3>	<Coding standards>	Process 04.02.00
<4>	FDD – SF024A_LrnPinionCentr_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

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

None

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
LrnPinionCentrInit1	None	RTE Init
LrnPinionCentrPer1	None	2 ms

Runnable	Scheduling Requirements	Trigger
SetInpPrm	None	On Event

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
None
LrnPinionCentr_START_SEC_CODE

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

Usage

Feature	RAM	ROM
None

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

19.2 - LrnPinionCentr_MDD

Module Design Document

For

LrnPinionCentr

12-Jan-2018

Prepared By:

Brendon Binder,

Nexteer Automotive,

Saginaw, MI, USA

Change History

Description	Author	Version	Date
Initial Version	ML	1.0	18-Sep-2017
Updated DaVinci graphic for Cal name change	BRB	2.0	12-Jan-2018

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 LrnPinionCentr & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of LrnPinionCentr 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: LrnPinionCentrInit1 9

5.1.1.1 Design Rationale 9

5.1.2 Per: LrnPinionCentrPer1 9

5.1.2.1 Design Rationale 9

5.2 Server Runnable 9

5.2.1 SetInpPrm 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 9

5.4.1 Local Function #1 9

5.4.1.1 Description 9

5.4.2 Local Function #2 9

5.4.2.1 Description 10

5.4.3 Local Function #3 10

5.4.3.1 Description 10

5.4.4 Local Function #4 10

5.4.4.1 Description 10

5.4.5 Local Function #5 10

5.4.5.1 Description 11

5.4.6 Local Function #6 11

5.4.6.1 Description 11

5.5 GLOBAL Function/Macro Definitions 11

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Appendix A Abbreviations and Acronyms 14

Appendix B Glossary 15

Appendix C References 16

Introduction

Purpose

Scope

LrnPinionCentr & High-Level Description

Refer FDD.

Design details of software module

Graphical representation of LrnPinionCentr

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 DataDict.m file from FDD for other constants	-	-	-

Software Component Implementation

Sub-Module Functions

Init: LrnPinionCentrInit1

Refer FDD Simulink model

Design Rationale

Refer to Anomaly EA4#17174. Implementation deviates to fix this issue for build.

Per: LrnPinionCentrPer1

Refer FDD Simulink Model

Design Rationale

None

Server Runnable

SetInpPrm

Refer FDD Simulink Model

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	RunMinMax	Type	Min	Max
Arguments Passed	HwAg_HwDeg_T_f32	float32	-1440.0	1440.0
	PinionCentrLrnEna_Cnt_T_logl	boolean	FALSE	TRUE
	*MaxHwPosn_HwDeg_T_f32	float32	-1440.0	1440.0
	*MinHwPosn_HwDeg_T_f32	float32	-1440.0	1440.0
Return Value	None

Description

Implementation of ‘Running MinMax’ function.

Local Function #2

Function Name	PosAgVelStCtrl1	Type	Min	Max
Arguments Passed	HwAg_HwDeg_T_f32	float32	-1440.0	1440.0
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350.0	1350.0
	TarMotVel_MotRadPerSec_T_f32	float32	0.0	1600.0
	*PinionCentrLrnSt_Cnt_T_u08	uint8	0	7
	*TqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	*MotPosnCmd_MotRad_T_f32	float32	-1440.0	1440.0
Return Value	None

Description

Implementation of ‘POSANGVEL State Control 1’ function.

Local Function #3

Function Name	PosMotTqStCtrl2	Type	Min	Max
Arguments Passed	*PinionCentrLrnSt_Cnt_T_u08	uint8	0	7
	*TqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	*MotPosnCmd_MotRad_T_f32	float32	-1440.0	1440.0
Return Value	None

Description

Implementation of ‘POSMTRTRQ State Control 2’ function.

Local Function #4

Function Name	NegAgVelStCtrl3	Type	Min	Max
Arguments Passed	HwAg_HwDeg_T_f32	float32	-1440.0	1440.0
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350.0	1350.0
	TarMotVel_MotRadPerSec_T_f32	float32	0.0	1600.0
	*PinionCentrLrnSt_Cnt_T_u08	uint8	0	7
	*TqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	*MotPosnCmd_MotRad_T_f32	float32	-1440.0	1440.0
Return Value	None

Description

Implementation of ‘NEGANGVEL State Control 3’ function.

Local Function #5

Function Name	NegMotTqStCtrl4	Type	Min	Max
Arguments Passed	MaxHwPosn_HwDeg_T_f32	float32	-1440.0	1440.0
	MinHwPosn_HwDeg_T_f32	float32	-1440.0	1440.0
	*PinionCentrLrnSt_Cnt_T_u08	uint8	0	7
	*TqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	*MotPosnCmd_MotRad_T_f32	float32	-1440.0	1440.0
Return Value	None

Description

Implementation of ‘NEGMTRTRQ State Control 4’ function.

Local Function #6

Function Name	MoveToStCtrl5	Type	Min	Max
Arguments Passed	HwAg_HwDeg_T_f32	float32	-1440.0	1440.0
	TarHwAg_HwDeg_T_f32	float32	-1440.0	1440.0
	MotVelCrf_MotRadPerSec_T_f32	float32	-1350.0	1350.0
	TarMotVel_MotRadPerSec_T_f32	float32	0.0	1600.0
	*PinionCentrLrnSt_Cnt_T_u08	uint8	0	7
	*TqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	*MotPosnCmd_MotRad_T_f32	float32	-1440.0	1440.0
Return Value	None

Description

Implementation of ‘MOVETO State Control 5’ function.

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.4.0 R4.0 Rev 3
2	MDD Guideline	EA4 01.00.01
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.01
5	FDD – SF024A_LrnPinionCentr_Design	See Synergy Subproject verison

19.3 - LrnPinionCentr_PeerReviewChecklist

Overview

Summary Sheet
Davinci Files
Source Code
PolySpace
MDD
Synergy Project

Sheet 1: Summary Sheet

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Summary Sheet

Component Short Name:

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

LrnPinionCentr

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

SF024A_LrnPinionCentr_Impl_1.1.0

Change Owner:

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

Brendon Binder

Work CR ID:

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

EA4#17556

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

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

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

Reviewed:

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

Yes

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci Files

Comments:

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

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

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

Sheet 2: Davinci Files

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

N/A

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

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

Yes

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

N/A

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

removed

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

N/A

Comments:

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

Runnable calling frequencies match DataDict.m file

N/A

Comments:

Runnable port access matches the DataDict.m file

N/A

Comments:

DataDict.m display variables: created as

N/A

Comments:

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

Per Instance Memory names and data types

N/A

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Brendon Binder

Review Date :

01/12/18

Component Type :

Application

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

Bri Spencer

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

Sheet 3: Source Code

Rev 2.00

29-Nov-17

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

Source File Name:

LrnPinionCentr.c

Source File Revision:

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

Header File Name:

Header File Revision:

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

MDD Name:

LrnPinionCentr_MDD.docx

Revision:

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

SWC Design Name:

SF024A_LrnPinionCentr_Design

Revision:

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

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 01.01

EA4 Software Naming Convention followed:

Version: 01.02

for variable names

N/A

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

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:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document or Model)

Yes

Comments:

in all areas where code was changed and/or Simulink

model was color-coded as changed and/or mentioned

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

layers of Simulink model for possible color coding not

reflected at a higher level, and includes looking at any

intermediate SWC Design versions between the version being

implemented and the version that was included as a

subproject in the previous implementation.)

Code comparison against previous version matches

Yes

Comments:

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

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

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

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Windows User: Intended Use: list version/revision of latest released Software Design and Coding Standards document. Version: 2.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

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:

Review Board:

Change Owner:

Brendon Binder

Review Date :

01/12/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Piyush Aggarwal

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

Bri Spencer

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

Sheet 4: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

LrnPinionCentr.c

Source File Revision:

2

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

1.04

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:

Brendon Binder

Review Date :

01/12/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Bri Spencer

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

Sheet 5: MDD

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

LrnPinionCentr_MDD.docx

MDD Revision:

2

Source File Name:

LrnPinionCentr.c

Source File Revision:

2

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Unit Tester)

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the SWC

N/A

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Brendon Binder

Review Date :

01/12/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Bri Spencer

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

Sheet 6: Synergy Project

Rev 2.00

29-Nov-17

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

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:

Brendon Binder

Review Date :

01/12/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Bri Spencer

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

20 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

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

20.2 - MotCtrlPrmEstimn_MDD

Module Design Document

For

MotCtrlPrmEstimn

06-Dec-2017

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Brendon Binder,

Nexteer Automotive,

Saginaw, MI, USA
Change 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
5	Removed local function which didn’t exist, migrated document to latest template	BRB	5.0	06-DEC-2017

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 MotCtrlPrmEstimn & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of MotCtrlPrmEstimn 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: MotCtrlPrmEstimnInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: MotCtrlPrmEstimnPer1 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.1.1 Per: MotCtrlPrmEstimnPer2 9

5.1.1.1 Design Rationale 9

5.1.1.2 Store Module Inputs to Local copies 9

5.1.1.3 (Processing of function)……… 9

5.1.1.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runnables 10

5.2.1 SetMotPrmNomEol 10

5.2.1.1 Design Rationale 10

5.2.1.2 (Processing of function)……… 10

5.2.2 SetMotPrmNomEol 10

5.2.2.1 Design Rationale 10

5.2.2.2 (Processing of function)……… 10

5.3 Interrupt Functions 10

5.4 Module Internal (Local) Functions 10

5.5 GLOBAL Function/Macro Definitions 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

Scope

MotCtrlPrmEstimn & High-Level Description

Please refer FDD

Design details of software module

Graphical representation of MotCtrlPrmEstimn

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
BITMASK2_CNT_U08	1	Cnt	2U
Refer constants from .m file

Software Component Implementation

Sub-Module Functions

Init: Init1

Design Rationale

Refer to FDD

Module Outputs

Refer to FDD

Per: Per1

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

Per: MotCtrlPrmEstimnPer2

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

Server Runnables

SetMotPrmNomEol

Design Rationale

None

(Processing of function)………

See GetMotPrmNomEol block in FDD

SetMotPrmNomEol

Design Rationale

None

(Processing of function)………

See SetMotPrmNomEol block in FDD

Interrupt Functions

None

Module Internal (Local) Functions

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

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

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	EA4 Software Naming Conventions	01.01.00
4	Software Design and Coding Standards	2.1
5	FDD – SF102A Motor Control Parameter Estimation	See Synergy subproject version

20.3 - MotCtrlPrmEstimn_PeerReviewChecklist

Overview

Summary Sheet
Davinci Files
Source Code
PolySpace
MDD
Synergy Project

Sheet 1: Summary Sheet

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Summary Sheet

Component Short Name:

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

MotCtrlPrmEstimn

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

SF102A_MotCtrlPrmEstimn_Impl_3.1.0

Change Owner:

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

Brendon Binder

Work CR ID:

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

EA4#16887

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

No

MDD

No

Source Code

No

PolySpace

No

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 SWC Owner and/or SWC Design author and Integrator and/or SW Lead as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
- To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
- .h file should be reviewed with the source file as part of the source file.

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

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

Sheet 2: Davinci Files

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

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

Yes

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

N/A

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

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 "Write (explicit)"

Yes

Comments:

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

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

No

Comments:

Data dictionary call location not correct. ICR EA4#18575 has been created to address this.

DataDict.m display variables: created as

Yes

Comments:

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

Per Instance Memory names and data types

Yes

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Brendon Binder

Review Date :

12/12/17

Component Type :

Application

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Gustavo Nunes

Comments:

Other Reviewer(s):

Matt Leser

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

Kathleen Creager

Sheet 3: Source Code

Rev 2.00

29-Nov-17

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

Source File Name:

MotCtrlPrmEstimn.c

Source File Revision:

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

Header File Name:

Header File Revision:

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

MDD Name:

MotCtrlPrmEstimn_MDD.docx

Revision:

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

SWC Design Name:

SF102A_MotCtrlPrmEstimn_Design

Revision:

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

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 01.01

EA4 Software Naming Convention followed:

Version: 01.02

for variable names

N/A

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

N/A

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

Yes

Comments:

from at least the changed areas of code

All variables are declared at the function level.

N/A

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document or Model)

Yes

Comments:

in all areas where code was changed and/or Simulink

model was color-coded as changed and/or mentioned

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

layers of Simulink model for possible color coding not

reflected at a higher level, and includes looking at any

intermediate SWC Design versions between the version being

implemented and the version that was included as a

subproject in the previous implementation.)

Code comparison against previous version matches

Yes

Comments:

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

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

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

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Windows User: Intended Use: list version/revision of latest released Software Design and Coding Standards document. Version: 2.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

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:

Review Board:

Change Owner:

Brendon Binder

Review Date :

12/12/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 4: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

MotCtrlPrmEstimn.c

Source File Revision:

7

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

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:

Brendon Binder

Review Date :

12/12/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 5: MDD

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

MotCtrlPrmEstimn_MDD.docx

MDD Revision:

5

Source File Name:

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

No

Comments:

Document was migrated to the latest template. The only change was removing a local function which didn't exist in the implementation.

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:

Talk to Kathleen about approving rationale - Completed 12/15/2017.

Review Board:

Change Owner:

Brendon Binder

Review Date :

12/12/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Steven Horwath

Sheet 6: Synergy Project

Rev 2.00

29-Nov-17

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

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:

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

Brendon Binder

Review Date :

12/12/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

21 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 5

2 References 6

3 Dependencies 7

3.1 SWCs 7

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

4 Configuration REQUIREMeNTS 8

4.1 Build Time Config 8

4.2 Configuration Files to be provided by Integration Project 8

4.3 Da Vinci Parameter Configuration Changes 8

4.4 DaVinci Interrupt Configuration Changes 8

4.5 Manual Configuration Changes 8

5 Integration DATAFLOW REQUIREMENTS 9

5.1 Required Global Data Inputs 9

5.2 Required Global Data Outputs 9

5.3 Specific Include Path present 9

6 Runnable Scheduling 10

7 Memory Map REQUIREMENTS 11

7.1 Mapping 11

7.2 Usage 11

7.3 NvM Blocks 11

8 Compiler Settings 12

8.1 Preprocessor MACRO 12

8.2 Optimization Settings 12

9 Appendix 13

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
<1>	<MDD Guidelines>	Process 04.02.00
<2>	<Software Naming Conventions>	Process 04.02.00
<3>	<Coding standards>	Process 04.02.00
<4>	FDD – 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

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

21.3 - MotCurrPeakEstimn_PeerReview

Overview

Summary Sheet
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. 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.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. Shawn Penning

Work CR ID:

EA4#17668

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:

No change to DataDict.m or .c file. Only .slx file changed so this baseline is to bring in new design .slx.

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 :

11/22/17

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

22 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
<1>	<MDD Guidelines>	Process 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

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

1 Abbrevations And Acronyms 5

2 References 6

3 MotCurrRegCfg & High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation of MotCurrRegCfg 8

4.2 Data Flow Diagram 8

4.2.1 Module level DFD 8

4.2.2 Sub-Module level DFD 8

4.3 COMPONENT FLOW DIAGRAM 8

5 Variable Data Dictionary 9

5.1 User defined typedef definition/declaration 9

5.2 Variable definition for enumerated types 9

6 Constant Data Dictionary 10

6.1 Program(fixed) Constants 10

6.1.1 Embedded Constants 10

6.1.1.1 Local 10

6.1.1.2 Global 10

6.1.2 Module specific Lookup Tables Constants 10

7 Software Module Implementation 11

7.1 Sub-Module Functions 11

7.2 Initialization Functions 11

7.2.1 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

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

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

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

23 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD – 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

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

23.3 - MotCurrRegVltgLimr_Peer Review Checklists

Overview

Summary Sheet
Davinci Files
Source Code
PolySpace
Synergy Project

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. 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.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#16889

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

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

Reviewed:

N/A

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci Files

Comments:

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

Sheet 2: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

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

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

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:

Brendon Binder

Review Date :

11/30/17

Component Type :

CDD

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Source Code Review)

Source File Name:

CDD_MotCurrRegVltgLimr.c

Source File Revision:

8

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

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

Working EA4 Software Naming Convention followed:

for variable names

N/A

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

N/A

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

N/A

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

N/A

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

N/A

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

N/A

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

N/A

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

N/A

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsiged conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

N/A

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

N/A

Comments:

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

All code is mapped with FDD (all FDD

N/A

Comments:

subfunctions and/or model blocks identified

with code comments; all code corresponds to

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

Review did not identify violations of other

Yes

Comments:

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 :

11/30/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_MotCurrRegVltgLimr.c

Source File Revision:

8

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:

Code Prover flags Dead Code. This is done in case there are out of range values given for the input 'MotCtrlMotAgElecDly'. Refer to Anomaly EA4#11890.

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed 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 :

11/30/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

General Notes / Comments:

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

Change Owner:

Brendon Binder

Review Date :

11/30/17

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

24 - Component Implementation

Component Implementation

Component Documentation

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

Working EA4 Software Naming Convention followed:

for variable names

N/A

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

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

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
<1>	FDD – 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

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

1 Abbrevations And Acronyms 5

2 References 6

3 motquaddetn & High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation of MOtquaddetn 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: 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

25 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
<1>	<MDD Guidelines>	Process 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

25.2 - MotRefMdl_MDD

Module Design Document

For

MotRefMdl

VERSION: 6.0

DATE: 15-Nov-2017

Prepared By:

Krishna Anne,

Software Component 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	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
6.	Fixed Design vs Implementation Mismatch	Krishna	6.0	15-Nov-2017

Table of Contents

1 Abbrevations And Acronyms 5

2 References 6

3 MotRefMdl & High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation of MotRefMdl 8

4.2 Data Flow Diagram 8

4.2.1 Module level DFD 8

4.2.2 Sub-Module level DFD 8

4.3 COMPONENT FLOW DIAGRAM 8

5 Variable Data Dictionary 9

5.1 User defined typedef definition/declaration 9

5.2 Variable definition for enumerated types 9

6 Constant Data Dictionary 10

6.1 Program(fixed) Constants 10

6.1.1 Embedded Constants 10

6.1.1.1 Local 10

6.1.1.2 Global 10

6.1.2 Module specific Lookup Tables Constants 10

7 Software Module Implementation 11

7.1 Sub-Module Functions 11

7.2 Initialization Functions 11

7.2.1 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 #8 Decoder

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)

Local Function #9 VltgSdlCalc

Function Name	VltgSdlCalc	Type	Min	Max
Arguments Passed	MotQuad_Cnt_T_enum	MotQuad1	1U	4U
	AbsltMotVelFiltLp_MotRadPerSec_T_u11p5	uint16	0U	1350U
Return Value	VltgSdl_Volt_T_f32	Boolean	0.0F	40.0F

Description

This function is split from Per1 to reduce the path count to less than 300.

GLObAL Function/Macro Definitions

None

TRANSIENT FUNCTIONS

None

Unit Test Considerations

None

Known Limitations With Design

None

Appendix

None

25.3 - MotRefMdl_Peer_Review

Overview

Summary Sheet
Davinci Files
Source Code
PolySpace
Synergy Project

Sheet 1: Summary Sheet

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Summary Sheet

Component Short Name:

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

SF103A_MotRefMdl_Impl

Revision / Baseline:

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

SF103A_MotRefMdl_Impl_4.0.0

Change Owner:

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

Shawn Penning

Work CR ID:

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

EA4#17534

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

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

Yes

Davinci Files

Comments:

Version rolled to 4.0 to match major revision number for design; previous implementations were not correct.

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

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

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

Sheet 2: Davinci Files

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

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

Yes

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

N/A

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

N/A

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

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 "Write (explicit)"

Yes

Comments:

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

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

Yes

Comments:

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

Per Instance Memory names and data types

Yes

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

01/03/18

Component Type :

Application

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

Sheet 3: Source Code

Rev 2.00

29-Nov-17

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

Source File Name:

MotRefMdl.c

Source File Revision:

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

Header File Name:

MotRefMdl.h

Header File Revision:

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

MDD Name:

MotRefMdl_MDD.doc

Revision:

7 (see comment)

SWC Design Name:

SF103A_MotRefMdl_Design

Revision:

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

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 1.01

EA4 Software Naming Convention followed:

Version: 1.02

for variable names

N/A

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

N/A

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

N/A

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document or Model)

N/A

Comments:

in all areas where code was changed and/or Simulink

model was color-coded as changed and/or mentioned

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

layers of Simulink model for possible color coding not

reflected at a higher level, and includes looking at any

intermediate SWC Design versions between the version being

implemented and the version that was included as a

subproject in the previous implementation.)

Code comparison against previous version matches

Yes

Comments:

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

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

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

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Windows User: Intended Use: list version/revision of latest released Software Design and Coding Standards document. Version: 2.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

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

No

Comments:

Beyond scope of this update; requires

"magic numbers": [N12]

designer input for naming to eliminate magic numbers.

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:

Not checked; beyond scope of this change.

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

N/A

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

N/A

Comments:

defined in the SWC Design DataDict.m file : [N53]

All code is mapped with SWC Design (all SWC

N/A

Comments:

Design subfunctions and/or model blocks identified

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

MDD is actually version 6 but appears in Synergy as 7. Header file is actually version 1 but appears in synergy as version 2. Both

files versions should be corrected during the next update of each file.

Review Board:

Change Owner:

Shawn Penning

Review Date :

01/03/18

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Kathleen Creager

Sheet 4: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

MotRefMdl.c

Source File Revision:

9

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

1.04

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:

Overflow and Divide by Zero flags were not checked as none of these variables were affected by this change. Future updates affecting these variables should verify that these

polyspace flags are not relevant.

Review Board:

Change Owner: Shawn Penning Review Date :

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

Other Reviewer(s):

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

Change Owner:

Shawn Penning

Review Date :

01/03/18

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

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

Shawn Penning

Review Date :

01/03/18

Lead Peer Reviewer:

Brendon Binder

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

26 - Component Implementation

Component Implementation

Component Documentation

26.1 - MotTqCalcd_IntegrationManual

Integration Manual

For

MotTqCalcd

VERSION: 1.0

DATE: 13-MARCH-2018

Prepared By:

TATA ELXSI,

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	TATA ELXSI	1.0	13-Mar-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 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
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	EA4 Software Naming Conventions	1.0.3 draft
2	Software Design and Coding Standards	3.0 draft
3	SF067A_MotTqCalcd_Design	See Synergy Sub Project Version

Dependencies

SWCs

Module	Required Feature
None

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

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

Note: There is a global Non-Rte function MotTqCalcd_Init. This init function is generated by embedded coder and is not present in the Simulink model. This function is always empty and shall not be called.

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 FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
MotTqCalcdInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
MotTqCalcdPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotTqCalcd_START_SEC_CODE	Code

* 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

26.2 - MotTqCalcd_MDD

Module Design Document

For

MotTqCalcd

Prepared For:

,

Prepared By:

TATA ELXSI,

INDIA

Change History

Description	Author	Version	Date
Initial version	TATA ELXSI	1	13-Mar-2018

Table of Contents

2 MotTqCalcd & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of MotTqCalcd 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: MotTqCalcdInit1 8

5.1.2 Init: MotTqCalcd_Init 8

5.1.3 Per: MotTqCalcdPer1 8

5.2 Server Runables 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 10

7 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 14

Introduction

Purpose

Module Design Document for SF067A_MotTqCalcd_Impl.

Scope

The following definitions are used throughout this document:

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

MotTqCalcd & High-Level Description

This function calculates motor torque estimate from measured Motor Currents or reference MotorCurrents based on the Motor Control and Thermal Protection LOA Mode.

Design details of software module

Graphical representation of MotTqCalcd

$C:\Users\guru.s\Desktop\Graphical view of Component\SF067A.JPG$

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

Software Component Implementation

Sub-Module Functions

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

Init: MotTqCalcdInit1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Init: MotTqCalcd_Init

Design Rationale

This init function is generated by embedded coder and is not present in the Simulink model.

This function is always empty and is not called.

Module Outputs

There are no outputs for this function.

Per: Per1

Design Rationale

Refer FDD

Store Module Inputs to Local copies

Refer FDD

(Processing of function)………

Refer FDD

Store Local copy of outputs into Module Outputs

Refer FDD

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
FDD	Functional Design Document. (See references)

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

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

26.3 - MotTqCalcd_Review

Overview

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

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

MotTqCalcd

Revision / Baseline:

SF067A_MotTqCalcd_AGC_Impl_1.0.0

Change Owner:

Nimmy Mathews

Work CR ID:

EA4#16545

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

Yes

Integration Manual

Yes

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

1

0.5

Component developer reviewers:

0

1

0.5

4

Other reviewers:

0

Total hours

1

2

1

4

Content reviewed

Lines of code:

90

Elements of .arxml content:

12

Pages of documentation:

26

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:

Remove Nexteer Interpolation and Fixed point subprojects - Done 3/22/2018

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/23/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Davinci Files

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

N/A

Comments:

versions (If available) and changes match changes

Initial version

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

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 "Write (explicit)"

Yes

Comments:

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

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

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

Per Instance Memory names and data types

N/A

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/21/18

Component Type :

Application

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

Siva

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

Sheet 4: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

MotTqCalcd.c

Source File Revision:

1

Header File Name:

MotTqCalcd.h

Header File Revision:

1

MDD Name:

MotTqCalcd_MDD.doc

Revision:

1

SWC Design Name:

SF067A_MotTqCalcd_Design

Revision:

1.0.1

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version:1.0.1

EA4 Software Naming Convention followed:

Version:1.0.3 draft

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

Yes

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

No

Comments:

and Version Control version in file comment block

Need new rules for autocoding

Change log contains detailed description of changes

No

Comments:

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

Need new rules for autocoding

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Verified using SIL testing

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

N/A

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

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Code comments are clear, correct, and adequate

Yes

Comments:

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

Comments are autogenerated.Need new rules for autocoding

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

No

Comments:

contain correct information: [N43]

Need new rules for autocoding

Code formatting (indentation, placement of

Yes

Comments:

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

As per the draft version 3.0

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All access of motor control loop data uses macros

N/A

Comments:

generated by the motor control manager

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

N/A

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

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

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/22/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Nimmy Mathews

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

Siva

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

Sheet 5: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

MotTqCalcd_MDD.doc

MDD Revision:

1

Source File Name:

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

Yes

Comments:

Design are noted and explained in Design Rationale

_Init function is not present in the model

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/22/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

MotTqCalcd.c

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

2.0 draft

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

N/A

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

2.0 draft

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:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/22/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 7: Integration Manual

Rev 2.01

21-Feb-18

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

Integration Manual Name:

MotTqCalcd_IntegrationManual.doc

Integration Manual Revision:

1

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

03/22/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

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

27 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

1.1 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD : 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.

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

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 MotTqCmdSca & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of MotTqCmdSca 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: MotTqCmdScaInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: MotTqCmdScaPer1 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runables 9

5.2.1 SetMotTqCmdSca 9

5.2.1.1 Design Rationale 9

5.2.1.2 (Processing of function)……… 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 10

5.5 GLOBAL Function/Macro Definitions 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

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

27.3 - MotTqCmdSca_Review

Review_Checklist

Overview

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

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. 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

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

Yes

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version:

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

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

28 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD : 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

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

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 MotTqTranlDampg & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of MotTqTranlDampg 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 8

4 Constant Data Dictionary 9

4.1 Program (fixed) Constants 9

4.1.1 Embedded Constants 9

5 Software Component Implementation 10

5.1 Sub-Module Functions 10

5.1.1 Init: 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 Module Internal (Local) 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

Appendix A Abbreviations and Acronyms 14

Appendix B Glossary 15

Appendix C References 16

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

28.3 - MotTqTranlDampg_Review

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

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

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

29 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD – 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

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

1 Abbrevations And Acronyms 5

2 References 6

3 MotVel & High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation OF MotVel 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.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.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

29.3 - MotVel_Peer Review Checklist

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

Change Owner:

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

Work CR ID:

EA4#19630

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:

Avinash James

Review Date :

01/19/18

Lead Peer Reviewer:

Jayakrishnan T

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

Source File Revision:

6

Source File Name:

CDD_MotVel_MotCtrl.c

Source File Revision:

3

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:

TBD

Quality Check Items:

Rationale is required for all answers of No

Working EA4 Software Naming Convention followed:

for variable names

N/A

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

N/A

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

No

Comments:

Design to be updated

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

No

Comments:

Magic numbers are used

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

Implementation done based on the a PSR code. Design work is in progress. Updated only the limit from 65535 to 65536

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed 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 :

01/19/18

Lead Peer Reviewer:

Jayakrishnan T

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Samanth K

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (PolySpace Review)

Source File Name:

CDD_MotVel.c

Source File Revision:

6

Source File Name:

CDD_MotVel_MotCtrl.c

Source File Revision:

3

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:

Avinash James

Review Date :

01/19/18

Lead Peer Reviewer:

Jayakrishnan T

Approved by Reviewer(s):

Yes

Other Reviewer(s):

30 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD : 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

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

1 Introduction 5

1.1 Purpose 5

2 PosnTrakgServo & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of PosnTrakgServo 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: PosnTrakgServoInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: PosnTrakgServoPer1 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runables 9

5.3 Interrupt Functions 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

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

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

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

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

Yes

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

and Work CR number

Code accurately implements FDD (Document or Model)

Yes

Comments:

Verified no Compiler Errors or Warnings

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

Yes

Comments:

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version:

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

31 - Component Implementation

Component Implementation

Component Documentation

31.1 - PullCmpActv_IntegrationManual

Integration Manual

For

Active Pull Compensation

VERSION:2.0

DATE: 22-DEC-2017

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	TATA	1.0	10/16/2015
2	Added FltInj	Krishna Anne	2.0	12/22/2017

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
1	FDD : SF013A_PullCmpActv_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
FLTINJENA	Set to ‘STD_ON’ for fault injection

Configuration Files to be provided by Integration Project

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

Runnable	Scheduling Requirements	Trigger
PullCmpActvPer1	None	RTE (2 ms)
PullCmpActvPer2	None	RTE (100 ms)
GetPullCmpPrm_Oper	None	On event
SetPullCmpLongTerm_Oper	None	On event
SetPullCmpShoTerm_Oper	None	On event
RstPullCmp_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

PullCmpLongTerm

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

None

31.2 - PullCmpActv_MDD

Module Design Document

For

Active Pull Compensation

Jan 17, 2017

Prepared For:

Software Engineering

,

Saginaw, MI, USA

Prepared By:

Matthew Leser,

,

Saginaw, MI, USA
Change History

Sl. No.	Description	Author	Version	Date
1	Initial Version	Akhil Krishna N D	1.0	16-Oct-2015
2	Updated to FDD version SF013A_PullCmpActv_Design_1.4.0	SB	2.0	29-Feb-2016
3	Updated to design version SF013A_PullCmpActv_Design_1.6.0	SN	3.0	20-Jun-2016
4	Updated to design version 2.0.0	ML	4.0	17-Jan-2017

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 Active Pull Compensation & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of Active Pull Compensation 7

3.2 Data Flow Diagram 8

3.2.1 Component level DFD 8

3.2.2 Function level DFD 8

4 Constant Data Dictionary 9

4.1 Program (fixed) Constants 9

4.1.1 Embedded Constants 9

5 Software Component Implementation 10

5.1 Sub-Module Functions 10

5.1.1 Init: PullCmpActvInit1 10

5.1.1.1 Design Rationale 10

5.1.1.2 Module Outputs 10

5.1.2 Per: PullCmpActvPer1 10

5.1.2.1 Design Rationale 10

5.1.2.2 Store Module Inputs to Local copies 10

5.1.2.3 (Processing of function)……… 10

5.1.2.4 Store Local copy of outputs into Module Outputs 10

5.1.3 Per: PullCmpActvPer2 10

5.1.3.1 Design Rationale 10

5.1.3.2 Store Module Inputs to Local copies 10

5.1.3.3 (Processing of function)……… 10

5.1.3.4 Store Local copy of outputs into Module Outputs 10

5.2 Server Runnables 11

5.2.1 GetPullCmpPrm 11

5.2.1.1 Design Rationale 11

5.2.1.2 (Processing of function)……… 11

5.2.2 RstPullCmp 11

5.2.2.1 Design Rationale 11

5.2.2.2 (Processing of function)……… 11

5.2.3 SetPullCmpLongTerm 11

5.2.3.1 Design Rationale 11

5.2.3.2 (Processing of function)……… 11

5.2.4 SetPullCmpShoTerm 11

5.2.4.1 Design Rationale 11

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

5.4.1.2 Processing 12

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

5.4.3.1 Design Rationale 13

5.4.3.2 Processing 13

5.5 GLOBAL Function/Macro Definitions 13

5.5.1 GLOBAL Function #1 13

5.5.1.1 Design Rationale 13

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

Active Pull Compensation & High-Level Description

The Active Pull Compensation Function corrects vehicle pull issues by compensating for HW torque offsets detected by the steering system. These torque offsets are classified as short-term and long-term, each of which is compensated for independently by the algorithm. When the compensation is applied, the need for the driver to provide a constant input torque to counter these offsets is greatly reduced.

Design details of software module

Graphical representation of Active Pull Compensation

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

Design Rationale

None

Module Outputs

None

Per: PullCmpActvPer1

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

Per: PullCmpActvPer2

Design Rationale

Please refer FDD.

Store Module Inputs to Local copies

Please refer FDD and design rationale noted above.

(Processing of function)………

Please refer FDD.

Store Local copy of outputs into Module Outputs

None

Server Runnables

GetPullCmpPrm

Design Rationale

None

(Processing of function)………

See GetPullCmpPrm block in FDD

RstPullCmp

Design Rationale

None

(Processing of function)………

See RstPullCmp block in FDD

SetPullCmpLongTerm

Design Rationale

None

(Processing of function)………

See SetPullCmpLongTerm block in FDD

SetPullCmpShoTerm

Design Rationale

None

(Processing of function)………

See SetPullCmpShoTerm block in FDD

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	ActvCmpEna	Type	Min	Max
Arguments Passed	PullCmpActvShoTermRst_Cnt_T_logl	boolean	FALSE	TRUE
	AbslHwTqFild_HwNwtMtr_T_f32	float32	0.0	10.0
	AbslHwAg_HwDeg_T_f32	float32	0.0	1440.0
	AbslVehYawRateFild_VehDegPerSec_T_f32	float32	0.0	128.0
	AbslVehLatA_MtrPerSecSqd_T_f32	float32	0.0	10.0
	PinionAgConf_Uls_T_f32	float32	0.0	1.0
	VehSpd_Kph_T_f32	float32	0.0	511.0
	VehSpdVld_Cnt_T_logl	boolean	FALSE	TRUE
	AbslHwVel_HwRadPerSec_T_f32	float32	0.0	42.0
	PullCmpCustLrngDi_Cnt_T_logl	Boolean	FALSE	TRUE
	VehYawRateVld_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	LrngEnad_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

None

Processing

(Place flowchart/design for local function)

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

Local Function #2

Function Name	CalcIntgrGain	Type	Min	Max
Arguments Passed	HwTq_HwNwtMtr_T_f32	float32	-10.0	10.0
	PullCmpShoTermPrev_HwNwtMtr_T_f32	float32	-10.0	10.0
Return Value	IntgtrGainShoTerm_Uls_T_f32	float32	0.0	1.0

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “CalcIntgtrGain” block of the Simulink model of the design

Local Function #3

Function Name	ErrIntgtrActvLim	Type	Min	Max
Arguments Passed	PullCmpActvShoTermRst_Cnt_T_logl	boolean	FALSE	TRUE
	IntgtrGainShoTerm_Uls_T_f32	float32	0.0	1.0
	PullErrShoTerm_HwNwtMtr_T_f32	float32	-10.0	10.0
	PullCmpShoTermPrev_HwNwtMtr_T_f32	float32	-10.0	10.0
	RampDwnStepSize_HwNwtMtr_T_f32	float32	0.0	0.6
	ShoTermRst_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	PullCmpShoTerm_HwNwtMtr_T_f32	float32	-10.0	10.0

Design Rationale

None

Processing

(Place flowchart/design for local function)

Refer to the “ErrIntgtr&ActvLim” block of the Simulink model of the design.

GLOBAL Function/Macro Definitions

GLOBAL Function #1

None

Design Rationale

processing

(Place flowchart/design for local function)

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

31.3 - PullCmpActv_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace
Integration Manual

Sheet 1: Summary Sheet

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Summary Sheet

Component Short Name:

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

SF013A_PullCmpActv_Impl

Revision / Baseline:

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

SF013A_PullCmpActv_Impl_2.2.0

Change Owner:

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

Krishna Anne

Work CR ID:

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

EA4#13663

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

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci Files

Comments:

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

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

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

Sheet 2: Synergy Project

Rev 2.00

29-Nov-17

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

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

Yes

Comments:

File/folder structure is correct per documentation in

Yes

Comments:

TL109A_SwcSuprt

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/25/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Davinci Files

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

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

Yes

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

N/A

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

N/A

Comments:

(name, data type)

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

N/A

Comments:

removed

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

N/A

Comments:

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

Runnable calling frequencies match DataDict.m file

N/A

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

N/A

Comments:

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

Per Instance Memory names and data types

Yes

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/25/18

Component Type :

Application

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Xin Liu

Comments:

Other Reviewer(s):

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

Sheet 4: Source Code

Rev 2.00

29-Nov-17

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

Source File Name:

PullCmpActv.c

Source File Revision:

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

Header File Name:

Header File Revision:

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

MDD Name:

PullCmpActv_MDD

Revision:

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

SWC Design Name:

SF013A_PullCmpActv_Design

Revision:

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

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 1.1

EA4 Software Naming Convention followed:

Version: 1.2

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

N/A

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

N/A

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document or Model)

Yes

Comments:

in all areas where code was changed and/or Simulink

model was color-coded as changed and/or mentioned

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

layers of Simulink model for possible color coding not

reflected at a higher level, and includes looking at any

intermediate SWC Design versions between the version being

implemented and the version that was included as a

subproject in the previous implementation.)

Code comparison against previous version matches

Yes

Comments:

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

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

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

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

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

Code comments are clear, correct, and adequate

Yes

Comments:

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

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

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

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

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

Yes

Comments:

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

Function comment blocks are per standards and

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

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

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/25/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

Integrator and or
SW lead:

Xin Liu

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 5: PolySpace

Rev 2.00

29-Nov-17

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

PullCmpActv.c

Source File Revision:

7

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.04.00

Poly Space version:

Windows User: eg. 2013b

R2013b

TL109A sub project version:

2.2.0

Quality Check Items:

Rationale is required for all answers of No

tools/local folders' header files are appropriate and

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

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

Yes

Comments:

with conditional compilation, has Polyspace been run with all

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

(Note which conditional compilation results have been archived)

Cyclomatic complexity and Static path count OK

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/25/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: Integration Manual

Rev 2.00

29-Nov-17

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

Integration Manual Name:

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

Integration Manual Revision:

kzshz2: Intended Use: Identify which version of the integration manual has been reviewed. 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:

Review Board:

Change Owner:

Krishna Anne

Review Date :

01/25/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Xin Liu

Comments:

Other Reviewer(s):

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

32 - Component Implementation

Component Implementation

Component Documentation

32.1 - PwrLimr_IntegrationManual

Integration Manual

For

PwrLimr

VERSION: 1.0

DATE: 20-APR-2018

Prepared By:

Shawn Penning,

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

Description	Author	Version	Date
Initial version	Shawn Penning	1.0	20-APR-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
1	EA4 Software Naming Conventions.doc	01.00.00
2	Software Design and Coding Standards.doc	2.1
3	SF019D_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

32.2 - PwrLimr_MDD

Module Design Document

For

PwrLimr

20-APR-2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Shawn Penning,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Shawn Penning	1.0	20-APR-2018

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 – SF019D Power Limiter	See Synergy subproject version

32.3 - PwrLimr_PeerReviewChecklist

Overview

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

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

PwrLimr

Revision / Baseline:

SF019D_PwrLimr_Impl_1.0.0

Change Owner:

Shawn Penning

Work CR ID:

EA4#22138

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

Yes

Integration Manual

Yes

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

2

1

0.5

Component developer reviewers:

0

1

0

4.5

Other reviewers:

0

0.5

0

Total hours

2

2.5

0.5

5

Content reviewed

Lines of code:

1443

Elements of .arxml content:

56

Pages of documentation:

26

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:

Review Board:

Change Owner:

Shawn Penning

Review Date :

04/23/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Davinci Files

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

All changed files have been compared against previous

N/A

Comments:

Initial Version

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

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 "Write (explicit)"

Yes

Comments:

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

Runnable calling frequencies match DataDict.m file

Yes

Comments:

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

Yes

Comments:

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

Per Instance Memory names and data types

N/A

Comments:

match DataDict.m file

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

04/23/18

Component Type :

Application

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Akilan Rathakrishnan

Comments:

Other Reviewer(s):

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

Sheet 4: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

PwrLimr.c

Source File Revision:

1

Header File Name:

Header File Revision:

MDD Name:

PwrLimr_MDD.docx

Revision:

1

SWC Design Name:

SF019D_PwrLimr_Design

Revision:

1

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 1.01

EA4 Software Naming Convention followed:

Version: 1.02

for variable names

Yes

Comments: Local variable name wrong. 04/23/18: corrected

for constant names

Yes

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

Yes

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

N/A

Comments: Initial version

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

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

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

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All access of motor control loop data uses macros

N/A

Comments:

generated by the motor control manager

All loops have termination conditions that ensure

Yes

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

Yes

Comments:

if needed: [N65]

All integer division and modulus operations

Yes

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

Yes

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

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

All code is mapped with SWC Design (all SWC

Yes

Comments:

Design subfunctions and/or model blocks identified

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

04/23/18

Lead Peer Reviewer:

Matt Leser

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

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

PwrLimr_MDD.docx

MDD Revision:

1

Source File Name:

PwrLimr.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: None

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the SWC

N/A

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments: None

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

04/23/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

PwrLimr.c

Source File Revision:

1

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

1.04

Poly Space version:

2013b

TL109A sub project version:

2.3.0

Quality Check Items:

Rationale is required for all answers of No

tools/local folders' header files are appropriate and

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

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

Yes

Comments:

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:

Review Board:

Change Owner:

Shawn Penning

Review Date :

04/23/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 7: Integration Manual

Rev 2.01

21-Feb-18

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

Integration Manual Name:

PwrLimr_IntegrationManual.doc

Integration Manual Revision:

1

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments: Initial version

General Notes / Comments:

Review Board:

Change Owner:

Shawn Penning

Review Date :

04/23/18

Lead Peer Reviewer:

Matt Leser

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

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

33 - Component Implementation

Component Implementation

Component Documentation

33.1 - SteerCmdArbnAndLim_IntegrationManual

Integration Manual

For

SteerCmdArbnAndLim

VERSION: 1.0

DATE: 27-APR-2018

Prepared By:

Software Group,

Nexteer Automotive,

Tychy, Poland

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	Marek Brykczyński	1.0	27-Apr-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
FDD	Functional Design Document

References

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

Sr. No.	Title	Version
1	EA4 Software Naming Conventions	1.02
2	Software Design and Coding Standards	2.01
3	SF112A_SteerCmdArbnAndLim_Design	See Synergy Sub Project Version

Dependencies

SWCs

Module	Required Feature
None

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

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

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 FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

No

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
SteerCmdArbnAndLimInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
SteerCmdArbnAndLimPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

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

N/A

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

33.2 - SteerCmdArbnAndLim_MDD

Module Design Document

For

SteerCmdArbnAndLim

April 27, 2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Tychy, Poland
Change History

Description	Author	Version	Date
Initial version	Marek Brykczyński	1	27-Apr-2018

Table of Contents

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 SteerCmdArbnAndLim & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of SteerCmdArbnAndLim 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: SteerCmdArbnAndLimInit1 8

5.1.2 Per: SteerCmdArbnAndLimPer1 8

5.2 Server Runables 8

5.2.1 Oper: SetManTqCmd_Oper 8

5.3 Interrupt Functions 8

5.4 Module Internal (Local) Functions 9

5.4.1 SteerCmdArbnAndLimStMac 9

5.4.2 SetNtcs 9

5.4.3 TranDeb 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

Module Design Document for SF112A_SteerCmdArbnAndLim_Impl.

Scope

The following definitions are used throughout this document:

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

SteerCmdArbnAndLim & High-Level Description

The Steer Command Arbitration And Limit arbitrates between different sources of Motor Torque Command based on a functional safety requirements and manufacturing process. It also provides means of applying limits to Motor Torque Command related to motor operation conditions and End Of Travel situations.

Design details of software module

Graphical representation of SteerCmdArbnAndLim

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 FDD for local constants.

Software Component Implementation

Sub-Module Functions

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

Init: Init1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Per: Per1

Design Rationale

Refer FDD

Store Module Inputs to Local copies

Refer FDD

(Processing of function)………

Refer FDD

Store Local copy of outputs into Module Outputs

Refer FDD

Server Runables

Oper: SetManTqCmd_Oper

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

Interrupt Functions

None

Module Internal (Local) Functions

SteerCmdArbnAndLimStMac

Function Name	SteerCmdArbnAndLimStMac	Type	Min	Max
Arguments Passed	MotTqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	LimdMotTqCmd_MotNwtMtr_T_f32	float32	-8.8	8.8
	ReqdMotTqCmdEna_Cnt_T_logl	boolean	FALSE	TRUE
	MotTqCmdNotLimd_Cnt_T_logl	boolean	FALSE	TRUE
Return Value	-	-	-	-

SetNtcs

Function Name	SetNtcs	Type	Min	Max
Arguments Passed	SteerCmdArbnAndLimSt_Cnt_T_u08	const pointer to const uint8	0	4
Return Value	-	-	-	-

TranDeb

Function Name	TranDeb	Type	Min	Max
Arguments Passed	MotTqCmdNotLimd_Cnt_T_logl	boolean	FALSE	TRUE
	TranCond_Cnt_T_u08	uint8	2	3
	TiThd_MilliSec_T_u16	uint16	FALSE	TRUE
	DebTiStor_Cnt_T_u32	const pointer to uint32	0	4294967295
Return Value	DebRes_Cnt_T_logl	boolean	FALSE	TRUE

Design Rationale

Refer FDD

Processing

Refer FDD

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

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

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.4.0 R4.0 Rev 3
2	MDD Guideline EA4	1.02
3	EA4 Software Naming Conventions	1.01
4	Software Design and Coding Standards	2.01
5	SF112A_SteerCmdArbnAndLim_Design	See Synergy Sub Project Version

33.3 - SteerCmdArbnAndLim_Review

Overview

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

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

SteerCmdArbnAndLim

Revision / Baseline:

SF112A_SteerCmdArbnAndLim_Impl_1.0.0

Change Owner:

Marek Brykczyński

Work CR ID:

EA4#23044

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

Yes

Integration Manual

Yes

Davinci Files

All required reviewers participated

Yes

Comments:

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

0.5

0

Component developer reviewers:

0.5

0

1

Other reviewers:

0

Total hours

1

0

1

Content reviewed

Lines of code:

all

Elements of .arxml content:

all

Pages of documentation:

N/A

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:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/27/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 3: Davinci Files

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port interfaces and datatypes are used

Yes

Comments:

(compare against TL107B to ensure only implementation

data types are used)

OBSOLETE/OBSELETE doesn’t appear in any arxml file

Yes

Comments:

Do all port interface names end in PortIf and a sequence

Yes

Comments:

number

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

For components with generated configurable content:

N/A

Comments:

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

N/A for changes

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

N/A

Comments:

the configuration header file(s) correctly

N/A for changes

All changed files have been compared against previous

Yes

Comments:

versions (If available) and changes match changes

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

and parent anomalies, and the SWC Design change log.

Davinci files accurately implement SWC Design (DataDict.m

Yes

Comments:

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

DataDict.m file was changed as shown by

comparing the DataDict.m from the current SWC Design

with the DataDict.m used in the previous implementation.

(This is NOT always the predecessor.)

Automated validation check is performed with no issues found

Yes

Comments:

Naming conventions followed. All names should

Yes

Comments:

match DataDict.m

Sender/Receiver port properties match DataDict.m file

Yes

Comments:

(name, data type, direction)

Calibration port properties match DataDict.m file

Yes

Comments:

(name, data type)

Sender/Receiver port initialization values match

Yes

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

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 "Write (explicit)"

Yes

Comments:

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

Runnable calling frequencies match DataDict.m file

N/A

Comments:

N/A for changes

Runnable port access matches the DataDict.m file

Yes

Comments:

DataDict.m display variables: created as

Yes

Comments:

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

Per Instance Memory names and data types

N/A

Comments:

match DataDict.m file

N/A for changes

NVM blocks match DataDict.m file

N/A

Comments:

(Named per naming convention. Default block

used if specified in DataDict.m file. Data type

matches DatatDict.m file)

Component is correct component type

Yes

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/27/18

Component Type :

Application

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

Sheet 4: Source Code

Rev 2.01

21-Feb-18

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

Source File Name:

SteerCmdArbnAndLim.c

Source File Revision:

1

Header File Name:

-

Header File Revision:

-

MDD Name:

SteerCmdArbnAndLim_MDD.docx

Revision:

1

SWC Design Name:

SF112A_SteerCmdArbnAndLim_Design

Revision:

1.0.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version: 01.01

EA4 Software Naming Convention followed:

Version: 1.02

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

Verified no possibility of uninitialized variables being

Yes

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

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

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

All code is mapped with SWC Design (all SWC

Yes

Comments:

Design subfunctions and/or model blocks identified

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/27/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Patryk Kołacki

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 5: MDD

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (MDD Review)

MDD Name:

SteerCmdArbnAndLim_MDD.docx

MDD Revision:

1

Source File Name:

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

Yes

Comments:

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

N/A

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

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

All implementation details that differ from the SWC

N/A

Comments:

Design are noted and explained in Design Rationale

All Unit Test Considerations have been described

N/A

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/27/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 6: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

SteerCmdArbnAndLim.c

Source File Revision:

1

Source File Name:

-

Source File Revision:

-

Source File Name:

-

Source File Revision:

-

EA4 Static Analysis Compliance Guideline version:

1.04

Poly Space version:

2013b

TL109A sub project version:

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

Cyclomatic complexity for one function is 11, this is acceptable in the subject case

and Coding Standards rule [N47]

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/27/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 7: Integration Manual

Rev 2.01

21-Feb-18

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

Integration Manual Name:

SteerCmdArbnAndLim_IntegrationManual.doc

Integration Manual Revision:

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

N/A

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

General Notes / Comments:

Review Board:

Change Owner:

Marek Brykczyński

Review Date :

04/27/18

Lead Peer Reviewer:

Krzysztof Byrski

Approved by Reviewer(s):

Yes

Integrator and or
SW lead:

Comments:

Other Reviewer(s):

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

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

34 - Component Implementation

Component Implementation

Component Documentation

34.1 - StOutpCtrl Review

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

Working EA4 Software Naming Convention followed:

for variable names

N/A

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

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

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
<1>	<FDD - <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>

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

1 Abbrevations And Acronyms 5

2 References 6

3 StOutpCtrl - High-Level Description 7

4 Design details of software module 8

4.1 Graphical representation of StOutpCtrl 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: 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

35 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

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

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

2 SysFricLrng High-Level Description 7

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

35.3 - SysFricLrng_PeerReviewChecklists

Overview

Summary Sheet
Synergy Project
Source Code
PolySpace
help
Version History

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

SysFricLrng

Revision / Baseline:

SF007A_SysFricLrng_Impl_3.1.0

Change Owner:

Matthew Leser

Work CR ID:

EA4#20204

Modified File Types:

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

Review Checklist Summary:

Reviewed:

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

N/A

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

N/A

Davinci Files

All required reviewers participated

No

Comments:

No other reviews besides Lead Reviewer were present due to timing constraints.

Approved by Steven Horwath - 6/8/2018

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:

7

Elements of .arxml content:

0

Pages of documentation:

0

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

Each peer review shall start with a clean copy of the latest peer review checklist template. Save in the doc folder of the component implementation, with the file name in the format SWCShortName_Review.xlsx. If the existing review in Synergy has a different name, the name must be changed IN SYNERGY (rather than by syncing in a new file with the new name) so that the file history will be properly maintained.

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

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

Sheet 2: Synergy Project

Rev 2.01

21-Feb-18

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

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

Yes

Comments:

File/folder structure is correct per documentation in

Yes

Comments:

TL109A_SwcSuprt

General Notes / Comments:

Review Board:

Change Owner:

Matthew Leser

Review Date :

06/04/18

Lead Peer Reviewer:

Shawn Penning

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:

SysFricLrng.c

Source File Revision:

10

Header File Name:

SysFricLrng.h

Header File Revision:

2

MDD Name:

SysFricLrng_MDD.docx

Revision:

6

SWC Design Name:

SF007A_SysFricLrng_Design

Revision:

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

Synergy version matches change history

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

Yes

Comments:

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

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

N/A

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.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 access of motor control loop data uses macros

N/A

Comments:

generated by the motor control manager

All loops have termination conditions that ensure

N/A

Comments:

finite loop iterations: [N63]

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

N/A

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsigned conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

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

All pointer dereferencing protects against

N/A

Comments:

null pointer if needed: [N70]

Component outputs are limited to the legal range

N/A

Comments:

defined in the SWC Design DataDict.m file : [N53]

All code is mapped with SWC Design (all SWC

Yes

Comments:

Design subfunctions and/or model blocks identified

with code comments; all code corresponds to

some SWC Design subfunction and/or model block):

[N40]

Any other violations of design and coding

N/A

Comments:

standards noticed during the review are noted in the

comments section for rework.

Anomaly or Design Work CR created

N/A

Comments: List Anomaly or CR numbers

for any SWC Design corrections needed

General Notes / Comments:

Review Board:

Change Owner:

Matthew Leser

Review Date :

06/04/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

See Summary Sheet

Integrator and or
SW lead:

Comments:

See Summary Sheet

Unit test co-ordinator:

Comments:

See Summary Sheet

Other Reviewer(s):

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

Sheet 4: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

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

Quality Check Items:

Rationale is required for all answers of No

tools/local folders' header files are appropriate and

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

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

Yes

Comments:

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:

Review Board:

Change Owner:

Matthew Leser

Review Date :

06/04/18

Lead Peer Reviewer:

Shawn Penning

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 5: 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 6: Version History



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










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

36 - Component Implementation

Component Implementation

Component Documentation

SysGlbPrm Review.html

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

Working EA4 Software Naming Convention followed:

for variable names

N/A

Comments:

for constant names

Yes

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

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

37 - Component Implementation

Component Implementation

Component Documentation

37.1 - SysKineAndEff_IntegrationManual

Integration Manual

For

SysKineAndEff

VERSION: 1.0

DATE: 13-MARCH-2018

Prepared By:

TATA ELXSI,

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	TATA ELXSI	1.0	13-Mar-2018

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 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
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	EA4 Software Naming Conventions	1.0.3 draft
2	Software Design and Coding Standards	3.0 draft
3	SF071A_SysKineAndEff_Design	See Synergy Sub Project Version

Dependencies

SWCs

Module	Required Feature
None

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

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

Note: There is a global Non-Rte function SysKineAndEff_Init. This init function is generated by embedded coder and is not present in the Simulink model. This function is always empty and shall not be called.

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 FDD

Required Global Data Outputs

Refer FDD

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
SysKineAndEffInit1	None	RTE(Init)

Runnable	Scheduling Requirements	Trigger
SysKineAndEffPer1	None	RTE(2ms)

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
SysKineAndEff_START_SEC_CODE	Code

* 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

37.2 - SysKineAndEff_MDD

Module Design Document

For

SysKineAndEff

March 13, 2018

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

TATA ELXSI,

INDIA

Change History

Description	Author	Version	Date
Initial version	TATA ELXSI	1	13-Mar-2018

Table of Contents

2 SysKineAndEff & High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of SysKineAndEff 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: SysKineAndEffInit1 8

5.1.2 Init: SysKineAndEff_Init 8

5.1.3 Per: SysKineAndEffPer1 8

5.2 Server Runables 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 10

7 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 14

Introduction

Purpose

Module Design Document for SF071A_SysKineAndEff_Impl.

Scope

The following definitions are used throughout this document:

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

SysKineAndEff & High-Level Description

In a variable ratio system the kinematic ratio and mechanical efficiency of the input and motor torque can change as the rack moves. This component calculates the Efficiencies and Ratios based on the Rack movement.

Design details of software module

Graphical representation of SysKineAndEff

$C:\Users\guru.s\Desktop\Graphical view of Component\SF071A.JPG$

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

Software Component Implementation

Sub-Module Functions

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

Init: SysKineAndEffInit1

Design Rationale

Refer FDD

Module Outputs

Refer FDD

Init: SysKineAndEff_Init

Design Rationale

This init function is generated by embedded coder and is not present in the Simulink model.

This function is always empty and is not called.

Module Outputs

There are no outputs for this function.

Per: SysKineAndEffPer1

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

None

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

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

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

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

37.3 - SysKineAndEff_Review

Overview

Summary Sheet
Synergy Project
Source Code
PolySpace
help
Version History

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

SysKineAndEff

Revision / Baseline:

SF071A_SysKineAndEff_AGC_Impl_1.1.0

Change Owner:

Nimmy Mathews

Work CR ID:

EA4#22823

Modified File Types:

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

Review Checklist Summary:

Reviewed:

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

N/A

MDD

Yes

Source Code

Yes

PolySpace

N/A

Integration Manual

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:

1

0.5

0

Component developer reviewers:

0

0.5

0

2

Other reviewers:

0

Total hours

1

0

2

Content reviewed

Lines of code:

2

Elements of .arxml content:

0

Pages of documentation:

0

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

Each peer review shall start with a clean copy of the latest peer review checklist template. Save in the doc folder of the component implementation, with the file name in the format SWCShortName_Review.xlsx. If the existing review in Synergy has a different name, the name must be changed IN SYNERGY (rather than by syncing in a new file with the new name) so that the file history will be properly maintained.

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

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

Sheet 2: Synergy Project

Rev 2.01

21-Feb-18

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

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

Yes

Comments:

File/folder structure is correct per documentation in

Yes

Comments:

TL109A_SwcSuprt

General Notes / Comments:

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

04/19/18

Lead Peer Reviewer:

Avinash James

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:

SysKineAndEff.c

Source File Revision:

2

Header File Name:

SysKineAndEff.h

Header File Revision:

2

MDD Name:

SysKineAndEff_MDD.docx

Revision:

1

SWC Design Name:

SF071A_SysKineAndEff_AGC_Design

Revision:

1.1.0

Quality Check Items:

Rationale is required for all answers of No

EA4 Common Naming Convention followed:

Version:1.0.1

EA4 Software Naming Convention followed:

Version:1.0.3 draft

for variable names

Yes

Comments:

for constant names

Yes

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

Yes

Comments:

written to component outputs or IRVs

Any requirements traceability tags have been removed

N/A

Comments:

from at least the changed areas of code

All variables are declared at the function level.

Yes

Comments:

Synergy version matches change history

No

Comments:

and Version Control version in file comment block

Need new rules for autocoding

Change log contains detailed description of changes

No

Comments:

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

Need new rules for autocoding

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Verified using SIL testing

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

N/A

Comments:

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

Initial version

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

Yes

Comments:

All other includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 3.0 draft

Code comments are clear, correct, and adequate

Yes

Comments:

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

Comments are autogenerated.Need new rules for autocoding

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]

Need new rules for autocoding

Function comment blocks are per standards and

No

Comments:

contain correct information: [N43]

Need new rules for autocoding

Code formatting (indentation, placement of

Yes

Comments:

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

As per the draft version 3.0

[N57], [N58], [N59]

Embedded constants used per standards; no

Yes

Comments:

"magic numbers": [N12]

As per the draft version 3.0

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,

Yes

Comments:

including all use of fixed point macros and

Though polyspace reports overflow/divide by zero, it was reviewed and concluded that this is because it takes the full range of float32 except one flagged for Nexteer Fixed point file. This has been fixed in this release.

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

Yes

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:

A limiter logic was added to avoid overflow in the code which was flagged for Nexteer fixed point file

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

04/18/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

SWC owner and/or
SWC Design author:

Comments:

Integrator and or
SW lead:

Comments:

Unit test co-ordinator:

Comments:

Other Reviewer(s):

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

Sheet 4: PolySpace

Rev 2.01

21-Feb-18

Nexteer SWC Implementation Peer Review Meeting Log (PolySpace Review)

Source File Name:

SysKineAndEff.c

Source File Revision:

2

Source File Name:

Source File Revision:

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

2.0 draft

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

Compliant with draft version for autocoding

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

The overflow and divide by zero warning in the earlier release is still valid except one for Nexteer Fixed point library which has been fixed in this release.

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Compliant with draft version 2.0 for autocoding

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:

All the overflow and divide by zero issues has been manually verified. This is also verified during SIL testing.

Review Board:

Change Owner:

Nimmy Mathews

Review Date :

04/18/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Sheet 5: 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 6: Version History



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










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

38 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	FDD : 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

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

1 Introduction 4

1.1 Purpose 4

1.2 Scope 4

2 TEstimn High-Level Description 5

3 Design details of software module 6

3.1 Graphical representation of TEstimn 6

3.2 Data Flow Diagram 6

3.2.1 Component level DFD 6

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: TEstimnInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: TEstimnPer1 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runables 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 9

5.5 GLOBAL Function/Macro Definitions 9

6 Known Limitations with Design 10

7 UNIT TEST CONSIDERATION 11

Appendix A Abbreviations and Acronyms 12

Appendix B Glossary 13

Appendix C References 14

Introduction

Purpose

Scope

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

38.3 - TEstimn_Review

Overview

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace
help
Version History

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

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:

Review Board:

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

Revision:

4

SWC Design Name:

SF006A_TEstimn_Design

Revision:

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:

Synergy version matches change history

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

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

Work CR number

Code accurately implements SWC Design (Document

Yes

Comments:

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

Simulink model was color-coded as changed and/or

mentioned in SWC Design change log.

Code comparison against previous version matches

Yes

Comments:

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

parent CRs and parent anomalies, and the SWC

Design change log.

Verified no Compiler Errors or Warnings

Yes

Comments:

(and verified for all possible combinations

of any conditionally compiled code)

Component.h is included

N/A

Comments:

All other includes are actually needed. (System includes

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:

Review Board:

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:

Review Board:

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:

Review Board:

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

39 - Component Implementation

Component Implementation

Component Documentation

39.1 - requirements

FDD	ID	Source	Function	Line(s)	Status	Comment
		.SwFileName	.SwFuncName	.SwLines	.SwStatus	.SwComment
SF043A	337	TqOscn.c	TqOscnPer1	431	I
SF043A	331	TqOscn.c	AmpRateLim	498	I
SF043A	330	TqOscn.c	AmpRateLim	505	I
SF043A	314	TqOscn.c	TqOscnPer1	286,358	I
SF043A	322	TqOscn.c	TqOscnPer1	286,358	I
SF043A	320	TqOscn.c	TqOscnPer1	286,358	I
SF043A	344	TqOscn.c	TqOscnPer1	443	I
SF043A	345	TqOscn.c	TqOscnPer1	447	I
SF043A	346	TqOscn.c	TqOscnPer1	445	I
SF043A	321	TqOscn.c	TqOscnPer1	286,358	I
SF043A	340	TqOscn.c	TqOscnPer1	447	I
SF043A	341	TqOscn.c	TqOscnPer1	443	I
SF043A	342	TqOscn.c	TqOscnPer1	445	I
SF043A	325	TqOscn.c	AmpRateLim	511	I
SF043A	326	TqOscn.c	AmpRateLim	511	I
SF043A	328	TqOscn.c	AmpRateLim	494,498,505	I
SF043A	329	TqOscn.c	AmpRateLim	494,498,505	I
SF043A	327	TqOscn.c	AmpRateLim	494,498	I
SF043A	300	TqOscn.c	TqOscnPer1	279	I
SF043A	301	TqOscn.c	TqOscnPer1	283	I
SF043A	302	TqOscn.c	TqOscnPer1	282	I
SF043A	304	TqOscn.c	TqOscnPer1	443	I
SF043A	305	TqOscn.c	TqOscnPer1	445	I
SF043A	306	TqOscn.c	TqOscnPer1	447	I
SF043A	332	TqOscn.c	TqOscnPer1	436	I
SF043A	298	TqOscn.c	TqOscnPer1	280	I
SF043A	299	TqOscn.c	TqOscnPer1	281	I

39.2 - TqOscn_IntegrationManual

Integration Manual

For

TqOscn

VERSION: 1.0

DATE: 05-Feb-2016

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 Anne	1.0	05-Feb-2016

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<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 : SF043A_TqOscn_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	NA

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
TqOscn	FLTINJENA should be set to STD_ON as required

Configuration Files to be provided by Integration Project

None

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
None

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
None

Manual Configuration Changes

Constant	Notes	SWC
NA

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

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

39.3 - TqOscn_MDD

Module Design Document

For

TqOscn

Feb 05, 2016

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	1.0	05-Feb-2016
Corrected ranges in local function #1	Krishna Kanth Anne	2.0	25-May-2016

Table of Contents

1 Introduction 5

1.1 Purpose 5

2 TqOscn & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of TqOscn 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: TqOscnInit1 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 None 9

5.1.3 Per: TqOscnPer1 9

5.1.3.1 Design Rationale 9

5.1.3.2 Store Module Inputs to Local copies 9

5.1.3.3 (Processing of function)……… 9

5.1.3.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runnables 9

5.3 Interrupt Functions 9

5.4 Module Internal (Local) Functions 10

5.4.1 Local Function #1 10

5.4.2 Local Function #2 10

5.5 GLOBAL Function/Macro Definitions 10

6 Known Limitations with Design 11

7 UNIT TEST CONSIDERATION 12

Appendix A Abbreviations and Acronyms 13

Appendix B Glossary 14

Appendix C References 15

Introduction

Purpose

TqOscn & High-Level Description

Please refer FDD.

Design details of software module

Graphical representation of TqOscn

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

Design Rationale

None

Module Outputs

None

Per: TqOscnPer1

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

Local Function #1

Function Name	AmpRateLim	Type	Min	Max
Arguments Passed	LimdAmp_MotNwtMtr_T_f32	Float32	0.0F	1.2F
	HwOscnRisngRampRate_MotNwtMtrPerSec_T_f32	Float32	0.1F	4400.0F
	HwOscnFallRampRate_MotNwtMtrPerSec_T_f32	Float32	-4400.0F	-0.1F
	HwOscnEna_Cnt_T_logl	Boolean	FALSE	TRUE
	*NonZeroAmpFlg_Cnt_T_logl	Boolean	FALSE	TRUE
Return Value	RateLimdAmp_MotNwtMtr_T_f32	Float32	0.0F	1.2F

Local Function #2

Function Name	ChkFlg	Type	Min	Max
Arguments Passed	PhaAg_MatRad_T_f32	Float32	0.125F	0.628F
Return Value	TqOscnPhaAg_MatRad_T_f32	Float32	0.0F	0.628F

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

39.4 - TqOscn_Review

Overview

Summary Sheet
Synergy Project
help
Version History

Sheet 1: Summary Sheet

Rev 2.01

21-Feb-18

Nexteer EA4 SWC Implementation Peer Review Summary Sheet

Component Short Name:

TqOscn

Revision / Baseline:

SF043A_TqOscn_Impl_1.2.2

Change Owner:

Matthew Leser

Work CR ID:

EA4#20850

Modified File Types:

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

Review Checklist Summary:

Reviewed:

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

N/A

MDD

N/A

Source Code

N/A

PolySpace

N/A

Integration Manual

N/A

Davinci Files

All required reviewers participated

Yes

Comments:

Update was to bring in new design version which only has EA3 to EA4 requirements migration

Migration did not occur because of the nature of the change - Approved by Steve

Time spent ( to the nearest half hour)

review preparation

review meeting

review follow-up

Change owner:

0

0.15

0

Component developer reviewers:

0

0.15

0

0.3

Other reviewers:

0

Total hours

0

0.3

0

0.3

Content reviewed

Lines of code:

0

Elements of .arxml content:

0

Pages of documentation:

0

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

Each peer review shall start with a clean copy of the latest peer review checklist template. Save in the doc folder of the component implementation, with the file name in the format SWCShortName_Review.xlsx. If the existing review in Synergy has a different name, the name must be changed IN SYNERGY (rather than by syncing in a new file with the new name) so that the file history will be properly maintained.

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

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

Sheet 2: Synergy Project

Rev 2.01

21-Feb-18

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

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

N/A

Comments:

See Summary Sheet

File/folder structure is correct per documentation in

N/A

Comments:

TL109A_SwcSuprt

See Summary Sheet

General Notes / Comments:

Review Board:

Change Owner:

Matthew Leser

Review Date :

04/13/18

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

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

40 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	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

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

40.3 - TunSelnAuthy_PeerReview

Overview

Summary Sheet
Davinci Files
Source Code
PolySpace
Synergy Project

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. 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

Working EA4 Software Naming Convention followed:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

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

41 - Component Implementation

Component Implementation

Component Documentation

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 file Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

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

Sr. No.	Title	Version
<1>	<MDD Guidelines>	Process 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

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

41.3 - VehSigCdng_PeerReviewChecklist

Overview

Summary Sheet
Synergy Project
Davinci Files
Source Code
PolySpace

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. 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

Working EA4 Software Naming Convention followed:

for variable names

N/A

Comments:

for constant names

N/A

Comments:

for function names

N/A

Comments:

for other names (component, memory

N/A

Comments:

mapping handles, typedefs, etc.)

All paths assign a value to outputs, ensuring

N/A

Comments:

all outputs are initialized prior to being written

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

N/A

Comments:

requirements tracability in the FDD

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

42 - Component Implementation

Component Implementation

Component Documentation

42.1 - VehSpdLimr_DesignReview

Overview

Summary Sheet
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. 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):

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

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document

References

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

Sr. No.	Title	Version
1	MDD Guidelines	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

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

1 VehSpdLimr High-Level Description 4

2 Design details of software module 5

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

5 Known Limitations with Design 8

6 UNIT TEST CONSIDERATION 9

Appendix A Abbreviations and Acronyms 10

Appendix B Glossary 11

Appendix C References 12

VehSpdLimr High-Level Description

The Vehicle Speed Limiting Function determines a limited assist torque command value as a function of vehicle speed and handwheel position to manage mechanical fatigue near end-of-travel positions.

Design details of software module

Graphical representation of VehSpdLimr

cid:image001.png@01D0D38B.56DD1A30

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

NA

Software Component Implementation

Sub-Module Functions

Init<Component Name>_Init<n>

Design Rationale

None

Module Outputs

None

Per: VehSpdLimrPer1

Design Rationale

FDD model contains a block named VehSpdLimrPer1

Store Module Inputs to Local copies

See FDD

(Processing of function)………

See FDD

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

Referring to anomaly EA4#1276, following are the discrepancies found:

1) Min/max values of HwAgEotCw, HwAgEotCcw, VehSpdLimrPosMaxOffs1, and VehSpdLimrPosMaxOffs2 need to be set to more realistic values; With the current ranges, there is a possiblity of converting negative numbers to unsigned data types. Note these ranges need to be coordinated with SF011A and SF018A.

2) Table VehSpdLimrMaxAssiY monotony needs to be identified as "Decreasing" the implementation assumes that VehSpdLimrMaxAssiY[0] is the maximum value of the table.

3) The concatenate block that creates the Y table for the linear interpolation block has the two inputs reversed the first input to the concatenation should be the max value of the VehSpdLimrMaxAssiY table, and the second input to the concatenation should be the output of the 1D Lookup block.

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

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

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

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