Nexteer Manufacturing Components(Applicative Software)

• 1: Component Implementation
• 1.1: 1. Overview
• 1.2: 2. General Negative Responses
• 1.3: 3. Document Conventions
• 1.4: CmnMfgSrv_PeerReviewChecklist
• 2: Component Implementation
• 2.1: CmnMfgSrvIf_IntegrationManual
• 2.2: CmnMfgSrvIf_PeerReviewChecklist
• 3: Component Implementation
• 3.1: MotVelCtrl_IntegrationManual
• 3.2: MotVelCtrl_MDD
• 3.3: MotVelCtrl_Review
• 4: Component Implementation
• 5: Component Implementation
• 6: Component Implementation
• 6.1: ProgMfgSrv_PeerReviewChecklist

1 - Component Implementation

Component Implementation

Component Documentation

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

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

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

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

1.4 - CmnMfgSrv_PeerReviewChecklist

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

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

Work CR ID:

EA4#17640

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

No

PolySpace

No

Integration Manual

Yes

Davinci Files

Comments:

Review covered changes for this revision only

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