Component Design

• 1: AR998A NxtrDet Functional Design Document
• 2: NxtrDet Design Peer Review Checklists

1 - AR998A NxtrDet Functional Design Document

Nexteer Det

FDD #AR998A

1. High Level Description 3

2. Function I/O 3

2.1. Input Description 3

2.2. Output Description 4

2.3. Sub-Function Data Flow 5

3. Design Rationale 6

4. Sub-Functions 6

4.1. Sub-Function: Initialization 6

4.1.1. Software Related Design 6

4.2. Sub-Function: Signal Processing of Battery and Switched Voltages 6

4.2.1. Hardware Related Design 6

4.2.2. Software Related Design 6

4.2.3. Sub Function Calibrations 6

* Location Legend 7

4.2.4. Signal Availability 7

4.3. Sub-Function: Next Sub-function 7

5. Timing / Execution Constraints 7

5.1. Rationale / Comments 7

5.2. Rates and State Execution 7

6. Additional Information 8

7. Revision Record & Change Approval 9

High Level Description

The Det (Development Error Tracer) is an AUTOSAR defined module used to aid in detecting development errors. Ideally, Det is used during project development only, and is disabled/turned off once the project development and testing reaches a stage where enough confidence has been gained in the design. Example of typical types of errors that are mapped to the Det module include:

• Incorrect usage of an API (e.g. arguments that are out of range)

• Attempted usage of a function that is not yet initialized

• Incorrect / incompatible configuration

In addition to Det usage already incorporated into 3rd party software (e.g. AUTOSAR BSW and MCAL modules), Det error checking usage can be incorporated into Nexteer designed components as additional error checking during project development via a specified interface into the Det AUTOSAR module. This design document outlines the details of the strategy of incorporating Det error checking in Nexteer designed components, defines the constants which control turning on and off specific Nexteer Det error checking functionality, and also centrally defines the constants controlling the Det “ModuleID” assigned to each Nexteer component which has Det functionality.

Function I/O

None - N/A

Input Description

None - N/A

Output Description

None - N/A

Data Flow

None –N/A

Design Rationale

Strategy Overview:

Det error checking is intended to strictly be an aid in detecting errors during project development. It is assumed that all Det error checking will be disabled at some point prior to production intent software builds. Additionally, Det error checking logic will have some impact on memory and cpu utilization metrics. For this reason, all Det logic will be conditionally compiled based on if any given component has its particular Det errors enabled.

The constants controlling these error enables are defined in this component (AR998A_NxtrDet). Additionally, the AUTOSAR Det module contains a global DET_ENABLED flag to be used as a single enable that can be used to turn off all Det error checks. Therefore, this global DET_ENABLED flag must be “enabled” in order for any Nexteer defined Det error checks to be enabled as shown below:

AUTOSAR Det API Interface Details:

void Det_ReportError(uint16 ModuleId, uint8 InstanceId, uint8 ApiId, uint8 ErrorId)

• ModuleId: Unique Id for each component that has Det Errors

• Nexteer’s components will start from 65535 and decrement (0-255 are reserved for AUTOSAR modules). This component (AR998A NxtrDet) will define all of the Nexteer defined ModuleId values.

• InstanceId: Only used if more than one instance of a module exists

• Always will be “0” for current Nexteer component designs

• ApiId: Unique Id within a module for a given API/Function

• Controlled by Nexteer component’s Det error design (value outside of scope of AR998A NxtrDet)

• ErrorId: Unique Id within a module’s API/Function for a specific error check being done

• Controlled by Nexteer component’s Det error design (value outside of scope of AR998A NxtrDet)

Nexteer Component Det Design Guidelines:

While the individual Det error detection design details for Nexteer components are outside the scope of this document, some high level design guidelines are given:

• Det error checking design details are outside the scope of FDD/Design component development. The software group will take responsibility for defining Det error checking in the implementation of the design where deemed appropriate (i.e. these are optional for implementation). Det design will be captured in the implementation documentation (e.g. MDD) of any given component (as opposed to in the design itself).

• All Det error checking logic will be conditionally compiled, and if turned off, the resulting compiled code will exactly match the specified design. (i.e. turning Det error checking off will remove all associated Det logic from the compilation). Further, implementation of Det error checking logic should not compromise the functionality of the core design (this should implicitly be verified during component unit testing).

Sub-Functions

None – N/A

Timing / Execution Constraints

None – N/A

Additional Information

Revision Record & Change Approval

2 - NxtrDet Design Peer Review Checklists

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

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. AR998A_NxtrDet_Design_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. Lucas Wendling

Work CR ID:

EA4#1915

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

FDD

Source Code

PolySpace

Integration Manual

Davinci Files

Comments:

Peer review of FDD

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.