Nexteer Manufacturing Components(Applicative Software)

• 1: Component Design
• 1.1: NM100A_MotVelCtrl_PeerReview_Design
• 2: Component Implementation
• 2.1: 1. Overview
• 2.2: 2. General Negative Responses
• 2.3: 3. Document Conventions
• 2.4: CmnMfgSrv_PeerReviewChecklist
• 3: Component Implementation
• 4: Component Implementation
• 4.1: MotVelCtrl_IntegrationManual
• 4.2: MotVelCtrl_MDD
• 4.3: MotVelCtrl_Review
• 5: Component Implementation
• 6: Component Implementation
• 7: Component Implementation

1 - Component Design

Component Design

Component Documentation

• NM100A_MotVelCtrl_PeerReview_Design.html

1.1 - NM100A_MotVelCtrl_PeerReview_Design

2 - Component Implementation

Component Implementation

Component Documentation

• 1. Overview.md
• 2. General Negative Responses.md
• 3. Document Conventions.md
• CmnMfgSrv_PeerReviewChecklist.html

2.1 - 1. Overview

Standards

Nexteer Manufacturing Services adhere to the ISO-14229 standard for Automotive Diagnostic Services as well as ISO-15765 (Transport Layer) standard for sending data packets over a CAN-Bus.

Connection Details

Request ID (to ECU): 0x712
Response ID (from ECU): 0x710

Byte Ordering

All data is transfered in Motorola format (most significant byte first - also known as big-endian).

NvM Values

For EA4, an ignition cycle or ECU reset is required to commit any and all stored values from Volatile Memory (RAM) to Non-Volatile Memory (NvM). When an auto trim, clear trim, write trim, or similar service is used to modify any value stored in NvM a flag is set within the controller indicating that the value is to be written to NvM on the next shutdown. The power cycle can be provided by means of a cycling of physical ignition (EPS ENA) or by issuing an ECU reset (11 60) service. The reception of a positive response from the ECU reset service indicates completion of NvM writes at which time it is safe to remove battery.

2.2 - 2. General Negative Responses

This is a comprehensive list of all negative response codes as defined by the ISO-14229 specification. A value of “Yes” in the columns below indicates that the NRC is applicable to ALL services of the corresponding type regardless of whether or not it is expressly listed in the “Unique Negative Responses” section of a specific service.

2.3 - 3. Document Conventions

Terms

NvM

Non-Volatile Memory

Hexadecimal Values

Hexadecimal values in this document will always be prefixed with “0x”. Hexadecimal format values in transaction snippets will be represented by a pair of x’s, for example:

xx

ASCII Values

ASCII text strings in transaction snippets will be represented by a pair of a’s, for example:

aa

Bitfields (Binary Values)

Binary values in this document will always be prefixed with “0b”. Binary (or bitfield) values in transaction snippets will be represented by single ‘b’ characters, for example:

b

Binary values will always be in groups that are multiples of 8 bits. In cases where some bits are unused, the unused bits will be marked as “Reserved”, for example.

bbbb b b b b
|    | | | |
|    | | | '-- Bit 0
|    | | '-- Bit 1
|    | '-- Bit 2
|    '-- Bit 3
'-- Reserved

Reserved bits should be passed as zeros on writes and reads.

Grouped Bytes

If bytes are grouped (for example, 4 bytes used to represent a single 32-bit value) the transaction snippet will show the bytes as being connected using the ‘o’ character, for example:

xx xx xx xx
|  |  |  |
'--o--o--o-- Represents a 32-bit value

Grouped values are always in Motorola format (i.e. most-significant byte first).

Floating Point Numbers

Floating point values are represented in transaction snippets as four ‘f’ character pairs, for example:

ff ff ff ff
|  |  |  |
'--o--o--o-- Single-precision floating point value

The four pairs represent the four bytes of data transmitted over CAN that make up the single precision float value. The four pairs will always be grouped using the conventions outlined in section 2.3 above.

Grouped values are always in Motorola format (i.e. most-significant byte first).

Units

Units in transaction snippets will be called out inside a pair of square braces, for example:

[MotNwtMtr]

If no units are specified, then the signal’s units are assumed to be Counts.

Ranges

Ranges for signals in transaction snippets will be called out inside a pair of parentheses, for example:

(minimum, maximum)

If no range is specified, then the range for the signal’s value is assumed to be bounded by the signals type.

• *The float32 type does not have a specific minimum nor maximum value and thus each signal is required to provide a valid range specific to each.

Scale/Offset

Scale values for signals in transaction snippets will be called out inside a pair of curly braces, for example:

{*1/(2^16)}

The above scale would imply multiplying the raw value from the CAN bus by 1/65536 to achieve the scaled representation. An example including an offset would look like this:

{*1/(2^4) +11.0125}

In this second example, the raw value from the bus shall have a scale of 1/16 applied and then an offset of +11.0125 added. Offsets may be positive or negative as indicated by the preceding sign.

2.4 - CmnMfgSrv_PeerReviewChecklist

Rev 6.0

28-Oct-14

Peer Review Summary Sheet

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

Component Revision:

kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. 0.16.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. Jared Julien

Change Request ID:

EA4#5582

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

X

Source Code

Data Dictionary

X

QAC

Integration Manual

X

Davinci Files

Comments:

Did not run Polyspace nor create MDDs or Integration Manual. All of these updates are planned for the future.

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