This is the multi-page printable view of this section. Click here to print.
Libraries
- 1: Component Design
- 2: Component Design
- 3: Component Design
- 4: Component Design
- 4.1: NxtrIntrpn FDD
- 5: Component Implementation
- 5.1: ArchGlbPrm Review
- 6: Component Implementation
- 7: Component Implementation
- 7.1: MotCtrlMgr Integration Manual
- 7.2: MotCtrlMgr Review
- 7.3: MotCtrlMgr_MDD
- 7.4: MotCtrlMgr DataDictionary Tool User Guide
- 8: Component Implementation
- 8.1: NxtrDet Integration Manual
- 8.2: NxtrDet Module Design Document
- 8.3: NxtrDet Peer Review Checklists
- 9: Component Implementation
- 9.1: NxtrFil Integration Manual
- 9.2: NxtrFil Review
- 10: Component Implementation
- 10.1: NxtrFixdPt Integration Manual
- 10.2: NxtrFixdPt Review
- 11: Component Implementation
- 11.1: NxtrIntrpn Integration Manual
- 11.2: NxtrIntrpn Review
- 12: Component Implementation
- 12.1: NxtrMath Integration Manual
- 12.2: NxtrMath Review
- 13: Component Implementation
- 13.1: NxtrTi Integration Manual
- 13.2: NxtrTi Review
1.1 - AR999A ArchGlbPrm
Functional Design Document
For
Architecture Global Parameters
VERSION: 1.0
DATE: 05-Mar-2015
Prepared By:
Nexteer Automotive,
Saginaw, MI, USA
Revision History
| Version | Description | Author | Section Modified | Date |
| 1.0 | Initial Version | Kathleen Creager | All | 05-Mar-2015 |
Table of Contents
4.1.1 float32 Constant specification 7
Abbrevations And Acronyms
| Abbreviation | Description |
|---|
References
This section lists the title & version of all the documents that are referred for development of this document
| Sr. No. | Title | Version |
|---|---|---|
Purpose
The purpose of this document is to describe the design of the Architecture Global Parameters component including the selection criteria for items to be included in the component and the method used for specifying the values of the items.
ArchGlbPrm Design
constants
The ArchGlbPrm component contains global constants that are either “mathematical” (e.g. the value of pi) or software-oriented (e.g. the value to be used as the zero threshold for float32 comparisons) in nature. The constants are defined in AR999A_ArchGlbPrm_DataDict.m and implemented as #define statements in “ArchGlbPrm.h”.
float32 Constant specification
For each float32 constant, the number of digits was chosen based on the smallest number of digits needed to give the same float32 representation as the value calculated by Excel. Rationale: this gives the most accurate representation possible for float32, while not containing a misleading number of digits beyond the resolution actually possible with float32.
Example procedure for determining the number of digits to use:
Enter the desired constant in Excel as a formula, e.g. “=PI()/2”
Copy the cell and paste as value into another cell
Select the new cell and copy the displayed value to the clipboard
Paste this value in a IEEE floating point conversion tool; record the single precision floating point representation (in hex), both rounded and unrounded.
Val = the pasted Excel value
X = number of digits in Val
Y = X
Do:
Y = Y - 1
Val1 = Val rounded to Y digits
While ((rounded single float representation of Val == rounded single float representation of Val1) AND
(unrounded single float representation of Val == unrounded single float representation of Val1))
Val2 = Val rounded to Y + 1 digits
Use Val2 as the constant value in the .h and .m files
1.2 - AR999A_ArchGlbPrm_PeerReview_Design
Overview
Peer Review InstructionsTechnical Review Checklist
Template Change Log
Sheet 1: Peer Review Instructions
| Instructions for Functional Design Package Peer Review | ||
| PRE-MEETING | ||
| Function Owner | Confirm that requirements are reviewed and approved PRIOR to the FDP peer review | |
| Function Owner | Start with latest version of the template for any "first reviews" - Continue to use existing temmplate for re-reviews | |
| Function Owner | Provide the functional design package (changed documents) to the invited attendees 1-2 working days in advance of review | |
| Function Owner | Notify the assigned peer reviewer and make sure they are prepared to do their function in the meeting | |
| Function Owner | Identify necessary attendance and invite to meeting | |
| Function Owner | Complete the "Author" column information for sections 1 through 3 prior to the review | |
| Function Owner | Complete the attendance invitation list in section 5 | |
| Function Owner | For Re-reviews only: Complete the column "remarks by author" to identify actions taken to address items found in earlier reviews. | |
| DURING MEETING | ||
| Function Owner | Present document changes to the review team | |
| Peer Reviewer | Capture attendance of the review | |
| Peer Reviewer | Capture actions and issues in section 4. Identify issue summary, Document type, Reference (Requirement ID, section number, etc), Defect Type and indicate status as "OPEN" | |
| POST MEETING | ||
| Function Owner | Follow up on all "open" items. Update "Summary of Resolution" to indicate what was done or decided. | |
| Function Owner | Schedule follow up review OR review open items with peer reviewer and obtain agreement to close | |
| Peer Reviewer | Close change request in system and confirm all associated tasks are complete. Upload peer review checklist (this document) with any FDP updates |
Sheet 2: Technical Review Checklist
Sheet 3: Template Change Log
| Rev | Change | Author |
| 01.00.05 | Added lesson learned #3.5 | MDK |
| 01.00.06 | Added lesson learned #3.6, 3.7 - Structure and writing of NVM in mfiles and models. | MDK |
| 02.00.00 | Combined ESG and Systems into one, compatible with Data_Management 2.13.0 of CreateDD and VerifyDD. | K. Derry |
2.1 - AR300A_MotCtrlMgr_FDD
Motor Control Manager
FDD #AR300A
.
1. High Level Description 4
2. Derived Requirements 4
3. Function I/O 5
3.1. Data Ownership 5
3.2. Input Description 5
3.3. Output Description 6
3.4. Sub-Function Data Flow 7
4. Design Rationale and Assumptions 8
5. Sub-Functions 8
5.1. Sub-Function: MotCtrlMgrPer1 – Motor Control To 2ms RTE interface 8
5.1.1. Hardware Related Design 8
5.1.2. Software Related Design 9
5.1.3. Sub Function Calibrations 9
5.1.4. Signal Availability 9
5.2. Sub-Function: MotCtrlMgrPer2 –2ms RTE to Motor Control interface 9
5.2.1. Hardware Related Design 9
5.2.2. Software Related Design 9
5.2.3. Sub Function Calibrations 10
5.2.4. Signal Availability 10
5.3. Sub-Function: MotCtrlMgrIrq: Motor Control Interrupt Service Routine 10
5.3.1. Hardware Related Design 10
5.3.2. Software Related Design 10
5.3.3. Sub Function Calibrations 10
5.3.4. Signal Availability 10
5.4. Sub-Function: Definition of Motor Control Data 10
5.4.1. Hardware Related Design 10
5.4.2. Software Related Design 10
5.4.3. Sub Function Calibrations 11
5.4.4. Signal Availability 11
5.5. Sub-Function: Non-RTE Enumeration Definitions 12
5.5.1. Hardware Related Design 12
5.5.2. Software Related Design 12
5.5.3. Sub Function Calibrations 12
5.5.4. Signal Availability 12
5.6. Sub-Function: Motor Control Data Access Macros 12
5.6.1. Hardware Related Design 12
5.6.2. Software Related Design 12
5.6.3. Sub Function Calibrations 12
5.6.4. Signal Availability 13
5.7. Sub-Function: Motor Control Data Signal Mapping 13
5.7.1. Hardware Related Design 13
5.7.2. Software Related Design 13
5.7.3. Sub Function Calibrations 13
5.7.4. Signal Availability 13
6. Timing / Execution Constraints 13
6.1. Rationale / Comments 13
6.2. Rates and State Execution 14
7. Serial Communications Interfaces 14
8. Additional Information 14
9. Revision Record & Change Approval 15
High Level Description
The Motor Control Manager component is responsible for three major tasks:
Defining and owning the Motor Control Interrupt routine
Defining and owning all Motor Control related global signals that are not handled by the RTE including providing interfaces for component access to these signals
Providing a standardized interface between the Motor Control related global signals and the RTE signals
Derived Requirements
None
Function I/O
Data Ownership
The following table shows the data that the MotCtrlMgr is expected to define and own. Please note that only a subset of this data is explicitly used as I/O for the MotCtrlMgr subfunctions.
| Data | Description |
|---|---|
| MotCtrlMgr_MotCtrlToTwoMilliSec_Rec | Structure containing all of the signals that are written by motor control scheduled runnables that are required to be read by 2ms RTE scheduled runnables. This structure is the structure that the Motor Control Runnables write to. The list of signals contained in this structure can change from program to program based on program dataflow requirements. |
| MotCtrlMgr_TwoMilliSecFromMotCtrl_Rec | Structure containing all of the signals that are written by motor control scheduled runnables that are required to be read by 2ms RTE scheduled runnables. This structure is the structure that the 2ms RTE scheduled runnables read from. The list of signals contained in this structure can change from program to program based on program dataflow requirements. |
| MotCtrlMgr_TwoMilliSecToMotCtrl_Rec | Structure containing all of the signals that are written by 2ms RTE scheduled runnables that are required to be read by motor control scheduled runnables. This structure is the structure that the 2ms RTE scheduled runnables write to. The list of signals contained in this structure can change from program to program based on program dataflow requirements. |
| MotCtrlMgr_MotCtrlFromTwoMilliSec_Rec | Structure containing all of the signals that are written by 2ms RTE scheduled runnables that are required to be read by motor control scheduled runnables. This structure is the structure that the Motor Control Runnables read from. The list of signals contained in this structure can change from program to program based on program dataflow requirements. |
| MotCtrlMgr_MotCtrlInt_Rec | Structure containing all of the signals that read and written only by motor control scheduled runnables (i.e. no interface with RTE scheduled runnables required). The list of signals contained in this structure can change from program to program based on program dataflow requirements. |
Input Description
The following inputs are used by this FDD. Source FDD, range, resolution are located in the FDD data dictionary.
| Input Name | Description |
|---|---|
| MotCtrlMgr_TwoMilliSecFromMotCtrl_Rec | See description above |
| <Signal1>…<Signal#> | All RTE signals coming from the 2ms RTE scheduled runnables that are required to be read by motor control scheduled runnables. The list of signals can change from program to program based on program dataflow requirements. |
Output Description
The following outputs are generated by this FDD. Source FDD, range, resolution are located in the FDD data dictionary.
| Output Name | Description |
|---|---|
| MotCtrlMgr_TwoMilliSecToMotCtrl_Rec | See description above |
| <SignalA>…<SignalX> | All RTE signals being read by 2ms RTE scheduled runnables that are written by motor control scheduled runnables. The list of signals can change from program to program based on program dataflow requirements. |
Sub-Function Data Flow
Design Rationale and Assumptions
The Motor Control Manager component is intended to provide a flexible design that will allow a consistent definition of all of the Motor Control related global signals, the Motor Control interrupt routine, and the interface between the Motor Control global signals and the RTE. The design is also partially influenced on the knowledge of how the DMA, ADC, and TSG3 hardware peripherals will be used for electrical architecture 4. The following assumptions were considered in the design, and further details on some of these items can be found later in this document:
The ADC0 will be used primarily for Motor Control ADC reads and the ADC1 will be used for 2ms ADC reads. The 2ms ADC reads will require explicit transfer from the Motor Control time domain to the 2ms time domain.
The DMA will be transferring ADC results from ADC result registers into RAM and therefore the ADC result RAM signals must be packed together in proper order. Additionally, all ADC results registers will be transferred, not just those that are used in a program.
The DMA will be transferring TSG3 PWM signals from RAM to TSG3 registers and therefore must be packed together in proper order. The signals names and ordering are as follows:
MotCtrlTSG3nDCMP0E, MotCtrlTSG3nCMP0E, MotCtrlTSG3nCMP12E
MotCtrlTSG3nCMPWE, MotCtrlTSG3nCMPVE, MotCtrlTSG3nCMPUE
All signals being transferred between the Motor Control and 2ms time domains will be done through the DMA and will require definition of signals for both time domains. This is why these signals are all packed together in a structure. Additionally, it is assumed that the DMA will be using 128 bit transfers for this data, and memory alignment and size of the structure are designed accordingly.
It is assumed that the RAM data structures that the DMA will be writing to will need to be placed in an isolated RAM location in memory and will therefore need special provisions to allow specific placement of this data in memory. It is also assumed the DMA will not have any specific restrictions on memory that it can read from.
Signals owned by the Motor Control Manager are not required to be defined as a structure. Enumerations, however, will be supported, but only for underlying datatypes of uint8, uint16, uint32.
The current design assumes only a 2ms interface to RTE is required
Sub-Functions
Sub-Function: MotCtrlMgrPer1 – Motor Control To 2ms RTE interface
Hardware Related Design
None
Software Related Design
Sub Function Calibrations
None
Signal Availability
None
Sub-Function: MotCtrlMgrPer2 –2ms RTE to Motor Control interface
Hardware Related Design
None
Software Related Design
Sub Function Calibrations
None
Signal Availability
None
Sub-Function: MotCtrlMgrIrq: Motor Control Interrupt Service Routine
Hardware Related Design
None
Software Related Design
The motor control interrupt routine needs to be configurable to allow flexibility in the runnable list that it contains as well as the order in which the runnables are called. Additionally, it will contain a loop counter that will toggle between 0 and 1 every motor control loop. Any runnables that need to be scheduled at a rate of MotorControlx2 will only run when the counter is equal to 1, whereas runnables that need to be scheduled at a rate of MotorControl will run regardless of the counter value. The counter should be initialized to 1 and will toggle after all runnables are executed.
Sub Function Calibrations
None
Signal Availability
None
Sub-Function: Definition of Motor Control Data
Hardware Related Design
None
Software Related Design
This sub-function defines the details of how the process for defining the motor control related signals contained in the Data Ownership section above. There are some high level details that hold true for all signals as follows:
Structures are used to implement the different data categories to group all of the data together
All structure elements are defined to pack the data into a structure in the most efficient manner. This involves grouping all of the same size datatypes together in the structure as well as grouping the different size groups in descending order of size (i.e. 32bit->16bit->8bit).
All structures are aligned to start at an address that is evenly divisible by 16 to allow for 128bit DMA transfers. Additionally, all structures will contain some pad bytes at the end of the structure to make the structure size (in bytes) evenly divisible by 16.
The following properties are needed to define the structure details:
Signal Name (without “MotCtrl” prefix if applicable)
Underlying signal datatype (float32, uint32, sint32, uint16, sint16, uint8, sint8, boolean)
If signal is enumerated the enumeration name is also needed
Initial Value of each signal
Size (for array handling)
Signal usage for each Motor Control related signal:
Signal read in a 2ms (or higher) function
Signal written in a 2ms (or higher) function
Signal read in Motor Control function
Signal written in a Motor Control function
MotCtrlMgr_MotCtrlToTwoMilliSec_Rec
If the motor control signal is written in a Motor Control function and read in a 2ms function, it would need to be placed in this structure. All signals in this structure should be prepended with “MotCtrl” given that this structure is accessed by Motor Control functions.
This structure should contain ADC1 result data as well given that it needs to be read by 2ms functions. This result data needs to be aligned at an address that is evenly divisible by 16 to allow for 128bit DMA transfers.
MotCtrlMgr_TwoMilliSecFromMotCtrl_Rec
This structure is an exact duplicate of MotCtrlMgr_MotCtrlToTwoMilliSec_Rec except “MotCtrl” is not prepended to each signal because this structure is accessed by 2ms functions.
MotCtrlMgr_TwoMilliSecToMotCtrl_Rec
If the motor control signal is written in a 2ms function and read in a Motor Control function, it would need to be placed in this structure.
MotCtrlMgr_MotCtrlFromTwoMilliSec_Rec
This structure is an exact duplicate of MotCtrlMgr_TwoMilliSecToMotCtrl_Rec except “MotCtrl” is prepended to each signal because this structure is accessed by Motor Control functions.
MotCtrlMgr_MotCtrlInt_Rec
If the motor control signal is written in a Motor Control function and is not read in a 2ms function, it would need to be placed in this structure.
This structure should contain ADC0 result data as well given that it needs to be read by Motor Control functions. This result data needs to be aligned at an address that is evenly divisible by 16 to allow for 128bit DMA transfers.
This structure should also contain TSG3 data as described in the above Design Assumptions section. This data must also be ensured to be aligned at an address that is evenly divisible by 4 to allow 32bit DMA transfers.
Sub Function Calibrations
None
Signal Availability
None
Sub-Function: Non-RTE Enumeration Definitions
Hardware Related Design
None
Software Related Design
Since certain signals that reside outside of the RTE may be required to be defined as enumerations, it is possible that there will not be visibility to the RTE defined enumerations. To resolve this, the Motor Control Manager will also allow definition of enumeration types and enumeration element names and values. This will need to be configurable on an as-needed basis. The following information is needed for this definition:
Enumeration Name
Underlying Enumeration Datatype (assumed uint8, uin16, and uint32 possibilities)
Enumeration Element Names and Values
Sub Function Calibrations
None
Signal Availability
None
Sub-Function: Motor Control Data Access Macros
Hardware Related Design
None
Software Related Design
To abstract the underlying structure definition for each Motor Control signal, the Motor Control Manager will define access macros for external software modules to use when accessing from Motor Control functions. These will either be accessing elements of MotCtrlMgr_MotCtrlInt_Rec, MotCtrlMgr_MotCtrlToTwoMilliSec_Rec, or MotCtrlMgr_MotCtrlFromTwoMilliSec_Rec depending on the signal access needs. The macros will be defined with the format:
MOTCTRLMGR_<SignalIdentifier>
Please note <SignalIdentifier> should always include the “MotCtrl” prefix since all signals accessed in Motor Control functions require this.
Sub Function Calibrations
None
Signal Availability
None
Sub-Function: Motor Control Data Signal Mapping
Hardware Related Design
None
Software Related Design
In order to resolve the fact that names for inputs and outputs will not always align, the motor control manager must take into account this when creating the Motor Control Data Access Macros (see corresponding Sub-Function in this document). The strategy adopted is that the access macros for inputs that connect to outputs of differing names will “map” to the data access macros for the outputs.
For example:
Input Name: MotCtrlSignalA
Output Name: MotCtrlSignal1
MOTCTRLMGR_<MotCtrlSignalA> access macro would “map” to MOTCTRLMGR_<MotCtrlSignal1> access macro and therefore ultimately be accessing the underlying structure element for MotCtrlSignal1. There would not be a separate structure element for MotCtrlSignalA.
Please note that for any given output, there could be multiple corresponding input signal names that it could “map” to.
Sub Function Calibrations
None
Signal Availability
None
Timing / Execution Constraints
Rationale / Comments
MotCtrlMgrPer1 should execute near the start of the 2ms loop before any other functions that need data that is output by runnables running at the Motor Control rate. The DMA transfer that is populating MotCtrlMgr_TwoMilliSecFromMotCtrl_Rec shall run before MotCtrlMgrPer1 and ideally enough other functionality runs in-between these two events that the transfer can complete with minimal wait time in MotCtrlMgrPer1 (since this function is waiting for DMA transfer completion).
MotCtrlMgrPer2 should execute as the final function of the forward path to allow minimal lag on computation of new PWM commands in the Motor Control loop.
Rates and State Execution
| Sub-Function Name | Rate (ms) |
|---|---|
| MotCtrlMgrPer1 | 2 (all system states) |
| MotCtrlMgrPer2 | 2 (all system states) |
Serial Communications Interfaces
None
Additional Information
Revision Record & Change Approval
| Rev | Date | Change Control # | Change Description |
| 1 | 04/22/15 | EA4#510 | Initial Version |
| 2 | 01/21/16 | EA4#3424 | Added signal mapping subfunction |
2.2 - MotCtrlMgr Design Peer Review Checklists
Overview
Summary SheetSynergy Project
FDD
Sheet 1: Summary Sheet
Sheet 2: Synergy Project
Sheet 3: FDD
3.1 - AR998A NxtrDet Functional Design Document
Nexteer Det
FDD #AR998A
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
4.3. Sub-Function: Next Sub-function 7
5. Timing / Execution Constraints 7
5.2. Rates and State Execution 7
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
| Input Name | Description |
Output Description
None - N/A
| Output Name | Description |
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
| Rev | Date | Change Control # | Change Description |
| 1 | 10/09/15 | EA4#1915 | Initial Version |
3.2 - NxtrDet Design Peer Review Checklists
Overview
Summary SheetSynergy Project
FDD
Sheet 1: Summary Sheet
Sheet 2: Synergy Project
Sheet 3: FDD
4.1 - NxtrIntrpn FDD
Functional Design Document
For
NxtrIntrpn
VERSION: 1.0
DATE: 20-Feb-2015
Prepared By:
Nexteer Automotive,
Saginaw, MI, USA
Revision History
| Version | Description | Author | Section Modified | Date | Approved By |
| 1.0 | Initial Version | K. Smith | All | 20-Feb-2015 | Nexteer |
Table of Contents
4.1.1 Linear Interpoliation Accuracy 8
4.2 Fixed X-Axis Linear Interpolation Functions 9
4.2.1.1 Truncating Functions 9
4.3 Variable X-Axis Linear Interpolation Functions 10
4.3.1.1 Truncating Functions 10
4.4.1 Common X Axis Bilinear Interpolation Functions 16
4.4.2 Variable X Axis Bilinear Interpolation Functions 19
5 Know Limitations With Design 22
7.1 Truncating Linear Interpolation Functions 24
7.1.1 Fixed X-Axis Interpolation Function 24
7.1.2 Variable X-Axis Interpolation Function 24
7.2 Rounding Linear Interpolation Functions 24
7.2.1 Fixed X-Axis Interpolation Function 24
7.2.2 Variable X-Axis Interpolation Function 24
Abbrevations And Acronyms
| Abbreviation | Description |
|---|---|
| BS | Bilinear Selection |
| API | Application Program Interface |
References
This section lists the title & version of all the documents that are referred for development of this document
| Sr. No. | Title | Version |
|---|---|---|
| Appendix C | RH850/P1x Series User’s Manual: Software | 0.10 Jan, 2014 |
Purpose
The purpose of this document is to describe the functions contained within the Nexteer interpolation library and as an API reference in designing functional requirements, models, and software components.
Interpolation Design
Linear Interpolation
Linear interpolation is used to determine an output value between a set of known data points for a given input. In the image below, the input point (x) is between the known points (x0,y0) and (x1,y1).
The linear interpolant is defined as the straight line between the two known points (x0,y0) and (x1,y1) and is defined in equation (1).
| $$\frac{\left( y - y_{0} \right)}{\left( x - x_{0} \right)} = \frac{\left( y_{1} - y_{0} \right)}{\left( x_{1} - x_{0} \right)}$$ | (1) |
|---|
Solving equation (1) for the desired output (y) is described below in equation (2).
| $$y = y_{0} + (y_{1} - y_{0})\frac{\left( x - x_{0} \right)}{\left( x_{1} - x_{0} \right)}$$ | (2) |
|---|
If the delta between neighboring points on the X-axis is the same, equation (2) can be modified with that delta as shown in equation (3).
$$x_{0} = \left\lfloor \frac{x}{\mathrm{\Delta}x} \right\rfloor*\mathrm{\Delta}x$$ $$y = y_{0} + (y_{1} - y_{0})\frac{\left( x - x_{0} \right)}{\mathrm{\Delta}x}$$ | (3) |
|---|
Linear Interpoliation Accuracy
The operations required to perform equations (2) and (3) shall be implemented using fixed point math. This is to save on execution time to perform the interpolation compared to using floating point math functions (See Appendix C). This also means that there can be information loss because the operations can produce results that have more bits than the operands. In order to keep the same number of bits as the operands, the answer must be rounded or truncated.
The interpolation library shall support both truncation and rounding methods in all linear interpolation functions. These methods are described in Appendix B. The error produced by the truncated function results can be +/- one count. Depending on the resolution of the calibration and the resolution required by the design, this may be negligible. The function designer shall use the truncation library functions in all cases where this error is acceptable in order to save on execution time.
Fixed X-Axis Linear Interpolation Functions
The following functions are available for linear interpolation with a fixed X-axis and are based on equation (3). The table below defines each argument used in the API. Note that some functions require and/or return unsigned or signed values. It is up to the designer to pick the proper interpolation function for their design.
| Argument | Notes |
|---|---|
| DeltaX | Provides the delta between points in the X-axis for interpolation. A value of 0 shall return the first value in YTbl. |
| YTbl[] | Y table values |
| Size | Number of elements in YTbl |
| Inp | Input value (x). Values that are less than or equal to DeltaX or larger than DeltaX * (Size – 1) will return the first or last value respectively from YTbl. |
API
The input and output variables are defined as uint16 or sint16 for purposes of min and max ranges. However, calibrations with different resolutions, for example u8p8, can be used because they are still represented as a 16-bit value within these functions.
Truncating Functions
| Function Name | LnrIntrpn_u16_u16FixdXu16VariY | Type | Min | Max |
| Arguments Passed | DeltaX | uint16 | 0 | 65535 |
| YTbl[] | uint16[] | 0 | 65535 | |
| Size | uint16 | 1 | 65535 | |
| Inp | uint16 | 0 | 65535 | |
| Return Value | uint16 | 0 | 65535 | |
| Function Name | LnrIntrpn_s16_u16FixdXs16VariY | Type | Min | Max |
| Arguments Passed | DeltaX | uint16 | 0 | 65535 |
| YTbl[] | sint16[] | -32768 | 32767 | |
| Size | uint16 | 1 | 65535 | |
| Inp | uint16 | 0 | 65535 | |
| Return Value | sint16 | -32768 | 32767 | |
Rounding Functions
| Function Name | LnrIntrpnWithRound_u16_u16FixdXu16VariY | Type | Min | Max |
| Arguments Passed | DeltaX | uint16 | 0 | 65535 |
| YTbl[] | uint16[] | 0 | 65535 | |
| Size | uint16 | 1 | 65535 | |
| Inp | uint16 | 0 | 65535 | |
| Return Value | uint16 | 0 | 65535 | |
| Function Name | LnrIntrpnWithRound_s16_u16FixdXs16VariY | Type | Min | Max |
| Arguments Passed | DeltaX | uint16 | 0 | 65535 |
| YTbl[] | sint16[] | -32768 | 32767 | |
| Size | uint16 | 1 | 65535 | |
| Inp | uint16 | 0 | 65535 | |
| Return Value | sint16 | -32768 | 32767 | |
Variable X-Axis Linear Interpolation Functions
The following functions are available for linear interpolation with a variable X-axis and are based on equation (2). The table below defines each argument used in the API. Note that some functions require and/or return unsigned or signed values. It is up to the designer to pick the proper interpolation function for their design.
| Argument | Notes |
|---|---|
| XTbl[] | X Table |
| YTbl[] | Y Table |
| Size | Number of elements in the XTbl and YTbl |
| Inp | Input value (x). Values that are less than or equal to XTbl[0] or larger than XTbl[Size – 1] will return the first or last value respectively from YTbl. |
API
The input and output variables are defined as uint16 or sint16 for purposes of min and max ranges. However, calibrations with different resolutions, for example u8p8, can be used because they are still represented as a 16-bit value within these functions.
Truncating Functions
| Function Name | LnrIntrpn_u16_u16VariXu16VariY | Type | Min | Max |
| Arguments Passed | XTbl[] | uint16[] | 0 | 65535 |
| YTbl[] | uint16[] | 0 | 65535 | |
| Size | uint16 | 1 | 65535 | |
| Inp | uint16 | 0 | 65535 | |
| Return Value | uint16 | 0 | 65535 | |
| Function Name | LnrIntrpn_u16_s16VariXu16VariY | Type | Min | Max |
| Arguments Passed | XTbl[] | sint16[] | -32768 | 32767 |
| YTbl[] | uint16[] | 0 | 65535 | |
| Size | uint16 | 1 | 65535 | |
| Inp | sint16 | -32768 | 32767 | |
| Return Value | uint16 | 0 | 65535 | |
| Function Name | LnrIntrpn_s16_s16VariXs16VariY | Type | Min | Max |
| Arguments Passed | XTbl[] | sint16[] | -32768 | 32767 |
| YTbl[] | sint16[] | -32768 | 32767 | |
| Size | uint16 | 1 | 65535 | |
| Inp | sint16 | -32768 | 32767 | |
| Return Value | sint16 | -32768 | 32767 | |
| Function Name | LnrIntrpn_s16_u16VariXs16VariY | Type | Min | Max |
| Arguments Passed | XTbl[] | uint16[] | 0 | 65535 |
| YTbl[] | sint16[] | -32768 | 32767 | |
| Size | uint16 | 1 | 65535 | |
| Inp | uint16 | 0 | 65535 | |
| Return Value | sint16 | -32768 | 32767 | |
Rounding Functions
| Function Name | LnrIntrpnWithRound_u16_u16VariXu16VariY | Type | Min | Max |
| Arguments Passed | XTbl[] | uint16[] | 0 | 65535 |
| YTbl[] | uint16[] | 0 | 65535 | |
| Size | uint16 | 1 | 65535 | |
| Inp | uint16 | 0 | 65535 | |
| Return Value | uint16 | 0 | 65535 | |
| Function Name | LnrIntrpnWithRound_u16_s16VariXu16VariY | Type | Min | Max |
| Arguments Passed | XTbl[] | sint16[] | -32768 | 32767 |
| YTbl[] | uint16[] | 0 | 65535 | |
| Size | uint16 | 1 | 65535 | |
| Inp | sint16 | -32768 | 32767 | |
| Return Value | uint16 | 0 | 65535 | |
| Function Name | LnrIntrpnWithRound_s16_s16VariXs16VariY | Type | Min | Max |
| Arguments Passed | XTbl[] | sint16[] | -32768 | 32767 |
| YTbl[] | sint16[] | -32768 | 32767 | |
| Size | uint16 | 1 | 65535 | |
| Inp | sint16 | -32768 | 32767 | |
| Return Value | sint16 | -32768 | 32767 | |
| Function Name | LnrIntrpnWithRound_s16_u16VariXs16VariY | Type | Min | Max |
| Arguments Passed | XTbl[] | uint16[] | 0 | 65535 |
| YTbl[] | sint16[] | -32768 | 32767 | |
| Size | uint16 | 1 | 65535 | |
| Inp | uint16 | 0 | 65535 | |
| Return Value | sint16 | -32768 | 32767 | |
Bilinear Interpolation
Bilinear interpolation is linear interpolation with expanded coverage into three dimensions. To calculate the result, three linear interpolations are required to be performed.
The first two interpolations are between the two data sets (shown in red and green in the image) and are described with the equations (4) and (5).
| $$Y_{1} = y_{0} + \left( y_{1} - y_{0} \right)\left( \frac{(x - x_{0})}{(x_{1} - x_{0})} \right)$$ | (4) |
|---|
| $$Y_{2} = y_{2} + \left( y_{3} - y_{2} \right)\left( \frac{(x - x_{2})}{(x_{3} - x_{2})} \right)$$ | (5) |
|---|
Equations (4) and (5) provide the endpoints for the interpolant between the two sets of data. The third interpolation determines how close the desired output is to each of the data sets. This is described in equation (6).
| $$y = Y_{1} + \left( Y_{2} - Y_{1} \right)\left( \frac{(BS - {BS}_{1})}{({BS}_{2} - {BS}_{1})} \right)$$ | (6) |
|---|
Since divisions are throughput intensive operations, equation (6) is not efficient for an embedded environment because it contains three division steps when substitutions are made for Y1 and Y2. However, the terms can be rearranged to reduce the amount of divisions for additional multiplications and additions, which typically are much less in throughput consumption. Staring with equations (4) and (5), the terms can be reordered into equations (7) and (8).
| $$Y_{1} = \frac{\left( {x - x}_{0} \right)\left( {y_{1} - y}_{0} \right) + \left( x_{1} - x_{0} \right)y_{0}}{\left( x_{1} - x_{0} \right)} = \frac{Y_{1_{Num}}}{Y_{1_{Den}}}$$ | (7) |
|---|
| $$Y_{2} = \frac{\left( x - x_{2} \right)\left( y_{3} - y_{2} \right) + \left( x_{3} - x_{2} \right)y_{2}}{\left( x_{3} - x_{2} \right)} = \frac{Y_{2_{Num}}}{Y_{2_{Den}}}$$ | (8) |
|---|
Equations (7) and (8) can be substituted back in equation (6) and the simplified result is shown in equation (9).
| $$y = \frac{\left( BS - {BS}_{1} \right)\left( Y_{2_{Num}} \right)\left( Y_{1_{Den}} \right) - \left( BS - {BS}_{1} \right)\left( Y_{1_{Num}} \right)\left( Y_{2_{Den}} \right) + \left( {BS}_{2} - {BS}_{1} \right)\left( Y_{1_{Num}} \right)\left( Y_{2_{Den}} \right)}{\left( {BS}_{2} - {BS}_{1} \right)\left( Y_{1_{Den}} \right)\left( Y_{2_{Den}} \right)}$$ | (9) |
|---|
Finally, the numerator in equation (9) can also be rearranged and split into multiple terms. The steps taken between equations (9) and (10) are provided in Appendix A. The final equation, requiring only one division step, is shown in equation (10).
Term1a = (x3−x2)(y1 − y0) Term1b = (x − x0)(BS2 − BS1) Term2a3a = (x2 − x0)(BS − BS1) Term2b = (x3 − x2)(y2 − y0) Term3b = (x − x3)(y3 − y2) $$y = y_{0} + \left( \frac{\left( {Term}_{2a3a} \right)\left( {Term}_{3b} \right) + \left( {Term}_{2a3a} \right)\left( {Term}_{2b} \right) + \left( {Term}_{1a} \right)\left( {Term}_{1b} \right)}{\left( {BS}_{2} - {BS}_{1} \right)\left( x_{1} - x_{0} \right)\left( x_{3} - x_{2} \right)} \right)$$ | (10) |
|---|
Common X Axis Bilinear Interpolation Functions
The following functions are available for bilinear interpolation with a common X-axis and are based on equation (10). The table below defines each argument used in the API. Note that some functions require and/or return unsigned or signed values. It is up to the designer to pick the proper interpolation function for their design.
| Argument | Notes |
|---|---|
| BilnrSeln | Bilinear Selection (BS-axis). If BilnrSeln is less than or equal to BilnrSelnTbl[0], BilnrSeln will be assigned BilnrSelnTbl[0] and the BS index will be set to 0. If BilnrSeln is greater or equal to BilnrSerlnTbl[BilnrSelnSize – 1], then the BilnrSeln will be assigned BilnrSelnTbl[BilnrSelnSize – 1] and the BS index will be set to BilnrSelnSize – 2. |
| Inp | Input (X-axis). If Inp is less than or equal to XTbl[0], the value will be assigned XTbl[0] and the X index will be set to 0. If it is greater than or equal to XTbl[XSize – 1], Inp will be assigned XTbl[XSize – 1] and the X index will be set to XSize – 2. |
| BilnrSelnTbl[] | Bilinear selection table |
| BilnrSelnSize | Number of elements in Bilinear selection table |
| XTbl[] | X table |
| MplYTbl[] | Y table (Number of elements = BilnrSelnSize * XSize) In most cases, Y table will be a 2-D table, and is declared as MplYTbl[BilnrSelnSize][XSize] |
| XSize | Size of X table |
API
The input and output variables are defined as uint16 or sint16 for purposes of min and max ranges. However, calibrations with different resolutions, for example u8p8, can be used because they are still represented as a 16-bit value within these functions.
| Function Name | BilnrIntrpnWithRound_u16_u16CmnXu16MplY | Type | Min | Max |
| Arguments Passed | BilnrSeln | uint16 | 0 | 65535 |
| Inp | uint16 | 0 | 65535 | |
| BilnrSelnTbl[] | uint16[] | 0 | 65535 | |
| BilnrSelnSize | uint16 | 1 | 65535 | |
| XTbl[] | uint16[] | 0 | 65535 | |
| MplYTbl[] | uint16[] | 0 | 65535 | |
| XSize | uint16 | 1 | 65535 | |
| Return Value | uint16 | 0 | 65535 | |
| Function Name | BilnrIntrpnWithRound_s16_u16CmnXs16MplY | Type | Min | Max |
| Arguments Passed | BilnrSeln | uint16 | 0 | 65535 |
| Inp | uint16 | 0 | 65535 | |
| BilnrSelnTbl[] | uint16[] | 0 | 65535 | |
| BilnrSelnSize | uint16 | 1 | 65535 | |
| XTbl[] | uint16[] | 0 | 65535 | |
| MplYTbl[] | sint16[] | -32768 | 32767 | |
| XSize | uint16 | 1 | 65535 | |
| Return Value | sint16 | -32768 | 32767 | |
| Function Name | BilnrIntrpnWithRound_s16_s16CmnXs16MplY | Type | Min | Max |
| Arguments Passed | BilnrSeln | uint16 | 0 | 65535 |
| Inp | sint16 | -32768 | 32767 | |
| BilnrSelnTbl[] | uint16[] | 0 | 65535 | |
| BilnrSelnSize | uint16 | 1 | 65535 | |
| XTbl[] | sint16[] | -32768 | 32767 | |
| MplYTbl[] | sint16[] | -32768 | 32767 | |
| XSize | uint16 | 1 | 65535 | |
| Return Value | sint16 | -32768 | 32767 | |
| Function Name | BilnrIntrpnWithRound_u16_s16CmnXu16MplY | Type | Min | Max |
| Arguments Passed | BilnrSeln | uint16 | 0 | 65535 |
| Inp | sint16 | -32768 | 32767 | |
| BilnrSelnTbl[] | uint16[] | 0 | 65535 | |
| BilnrSelnSize | uint16 | 1 | 65535 | |
| XTbl[] | sint16[] | -32768 | 32767 | |
| MplYTbl[] | uint16[] | 0 | 65535 | |
| XSize | uint16 | 1 | 65535 | |
| Return Value | uint16 | 0 | 65535 | |
Variable X Axis Bilinear Interpolation Functions
The following functions are available for bilinear interpolation with a variable X-axis and are based on equation (10). The table below defines each argument used in the API. Note that some functions require and/or return unsigned or signed values. It is up to the designer to pick the proper interpolation function for their design.
| Argument | Notes |
|---|---|
| BilnrSeln | Bilinear Selection (BS-axis). If BilnrSeln is less than or equal to BilnrSelnTbl[0], BilnrSeln will be assigned BilnrSelnTbl[0] and the BS index will be set to 0. If BilnrSeln is greater or equal to BilnrSerlnTbl[BilnrSelnSize – 1], then the BilnrSeln will be assigned BilnrSelnTbl[BilnrSelnSize – 1] and the BS index will be set to BilnrSelnSize – 2. |
| Inp | Input (X-axis). If Inp is less than or equal to XTbl[0], the value will be assigned XTbl[0] and the X index will be set to 0. If it is greater than or equal to XTbl[XSize – 1], Inp will be assigned XTbl[XSize – 1] and the X index will be set to XSize – 2. |
| BilnrSelnTbl[] | Bilinear selection table |
| BilnrSelnSize | Number of elements in Bilinear selection table |
| MplXTbl [] | X table (Number of elements = BilnrSelnSize * XSize) In most cases, X table will be a 2-D table, and is declared as MplXTbl[BilnrSelnSize][XSize] |
| MplYTbl[] | Y table (Number of elements = BilnrSelnSize * XSize) In most cases, Y table will be a 2-D table, and is declared as MplYTbl[BilnrSelnSize][XSize] |
| XSize | Size of X table |
API
The input and output variables are defined as uint16 or sint16 for purposes of min and max ranges. However, calibrations with different resolutions, for example u8p8, can be used because they are still represented as a 16-bit value within these functions.
| Function Name | BilnrIntrpnWithRound_u16_u16MplXu16MplY | Type | Min | Max |
| Arguments Passed | BilnrSeln | uint16 | 0 | 65535 |
| Inp | uint16 | 0 | 65535 | |
| BilnrSelnTbl[] | uint16[] | 0 | 65535 | |
| BilnrSelnSize | uint16 | 1 | 65535 | |
| MplXTbl[] | uint16[] | 0 | 65535 | |
| MplYTbl[] | uint16[] | 0 | 65535 | |
| XSize | uint16 | 1 | 65535 | |
| Return Value | uint16 | 0 | 65535 | |
| Function Name | BilnrIntrpnWithRound_u16_s16MplXu16MplY | Type | Min | Max |
| Arguments Passed | BilnrSeln | uint16 | 0 | 65535 |
| Inp | sint16 | -32768 | 32767 | |
| BilnrSelnTbl[] | uint16[] | 0 | 65535 | |
| BilnrSelnSize | uint16 | 1 | 65535 | |
| MplXTbl[] | sint16[] | -32768 | 32767 | |
| MplYTbl[] | uint16[] | 0 | 65535 | |
| XSize | uint16 | 1 | 65535 | |
| Return Value | uint16 | 0 | 65535 | |
| Function Name | BilnrIntrpnWithRound_s16_s16MplXs16MplY | Type | Min | Max |
| Arguments Passed | BilnrSeln | uint16 | 0 | 65535 |
| Inp | sint16 | -32768 | 32767 | |
| BilnrSelnTbl[] | uint16[] | 0 | 65535 | |
| BilnrSelnSize | uint16 | 1 | 65535 | |
| MplXTbl[] | sint16[] | -32768 | 32767 | |
| MplYTbl[] | sint16[] | -32768 | 32767 | |
| XSize | uint16 | 1 | 65535 | |
| Return Value | sint16 | -32768 | 32767 | |
| Function Name | BilnrIntrpnWithRound_s16_u16MplXs16MplY | Type | Min | Max |
| Arguments Passed | BilnrSeln | uint16 | 0 | 65535 |
| Inp | uint16 | 0 | 65535 | |
| BilnrSelnTbl[] | uint16[] | 0 | 65535 | |
| BilnrSelnSize | uint16 | 1 | 65535 | |
| MplXTbl[] | uint16[] | 0 | 65535 | |
| MplYTbl[] | sint16[] | -32768 | 32767 | |
| XSize | uint16 | 1 | 65535 | |
| Return Value | sint16 | -32768 | 32767 | |
Known Limitations With Design
The linear interpolation functions are implemented using signed 32-bit values for the calculation of the interpolation. If the product of the X and Y terms in the numerator are greater than or equal to 2,147,483,648 or 0x80000000 the rounding functions will apply the rounding incorrectly resulting in a 1 count error due to an overflow of the sign-bit. The truncating functions should be used in these situations.
The bilinear functions are calculated using single-precision floating point math.
Values of tables for linear interpolation X-axis and each row in the x-axis in a bilinear interpolation are assumed to be increasing in value.
Consider the array of values below:
| Index | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|---|
| X-Axis | 0 | 1 | 2 | 2 | 2 | 2 | 2 | 2 |
| Y-Axis | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 |
These values can be used in the interpolation library. If the input value is less than 2, then the interpolation will be performed as described in this document. If the value is greater than or equal to 2, then index 7 will be returned. This also is true for the bilinear selection table.
Consider the array of values below:
| Index | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|---|
| X-Axis | 0 | 1 | 2 | 2 | 2 | 2 | 2 | 4 |
| Y-Axis | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 |
These values can also be used in the interpolation library. If the input value is less than 2, then the interpolation will be performed as described in this document. If the value is greater than or equal to 2 and less than 4, the function will interpolate between index 6 and 7 as described in this document. If the value is greater than or equal to 4, index 7 is returned. This also is true for the bilinear selection table.
All division operations in linear interpolation functions are not protected for division by zero to save on execution time. The designer shall take all efforts to ensure that the values selected for the tables will not result in a divide by zero operation.
Appendix A
The following section will demonstrate how equation (9) is recorded into the equation (10) described in the section Bilinear Interpolation.
Using equation (9) from section 5.2, the numerator and denominator can be subsitutituted for ynum and yden as shown in equation (A1).
| $$y = \frac{\left( BS - {BS}_{1} \right)\left( Y_{2_{Num}} \right)\left( Y_{1_{Den}} \right) - \left( BS - {BS}_{1} \right)\left( Y_{1_{Num}} \right)\left( Y_{2_{Den}} \right) + \left( {BS}_{2} - {BS}_{1} \right)\left( Y_{1_{Num}} \right)\left( Y_{2_{Den}} \right)}{\left( {BS}_{2} - {BS}_{1} \right)\left( Y_{1_{Den}} \right)\left( Y_{2_{Den}} \right)} = \frac{y_{num}}{y_{den}}$$ | (A1) |
|---|
Substituting back in all the terms in ynum, the numerator can be simplified as shown in equations A2 to A4.
Expanding the Y1Num and Y2Num term:
| ynum = (BS−BS1)(Y1Den)((x−x2)(y3−y2)+(Y2Den)y2) − (BS−BS1)(Y2Den)((x − x0)(y1 − y0)+(Y1Den)y0) + (BS2−BS1)(Y2Den)((x − x0)(y1 − y0)+(Y1Den)y0) |
|---|
| ynum = (BS−BS1)(Y1Den)(x−x2)(y3−y2) + (BS−BS1)(Y1Den)(Y2Den)y2 − (BS−BS1)(Y2Den)(x − x0)(y1 − y0) − (BS−BS1)(Y2Den)(Y1Den)y0 + (BS2−BS1)(Y2Den)(x − x0)(y1 − y0) + (BS2−BS1)(Y2Den)(Y1Den)y0 | (A2) |
|---|
Simplifying (A2)
| ynum = (BS−BS1)(Y1Den)(x−x2)(y3−y2) + (BS−BS1)(Y1Den)(Y2Den)(y2−y0) + (BS2−BS)(Y2Den)(x − x0)(y1 − y0) + (yden)(y0) | (A3) |
|---|
Now equation (A3) can be grouped into smaller terms and simplified.
| ynum = (BS−BS1)(x1−x0)(x−x2)(y3−y2) + (BS−BS1)(x1−x0)(x3−x2)(y2−y0) + (BS2−BS)(x − x0)(y1 − y0)(x3−x2) + (yden)(y0) |
|---|
Term1a = (x3−x2)(y1 − y0) Term1b = (BS2 − BS1)(x − x0) Term2a3a = (BS − BS1)(x1 − x0) Term2b = (x3 − x2)(y2 − y0) Term3b = (x − x2)(y3 − y2) $$y = \frac{y_{num}}{y_{den}} = y_{0} + \left( \frac{\left( {Term}_{2a3a} \right)\left( {Term}_{3b} \right) + \left( {Term}_{2a3a} \right)\left( {Term}_{2b} \right) + \left( {Term}_{1a} \right)\left( {Term}_{1b} \right)}{\left( {BS}_{2} - {BS}_{1} \right)\left( x_{1} - x_{0} \right)\left( x_{3} - x_{2} \right)} \right)$$ | (A4) |
|---|
Appendix B
The equations below can be used by a designer to see the impact of the truncating and rounding functions on their design.
Truncating Linear Interpolation Functions
From equations (2) and (3), the truncated result can be characterized by equations (B1) and (B2).
Fixed X-Axis Interpolation Function
| $$y = y_{0} + \left\lfloor (y_{1} - y_{0})\frac{\left( x - x_{0} \right)}{\mathrm{\Delta}x} \right\rfloor$$ | (B1) |
|---|
Variable X-Axis Interpolation Function
| $$y = y_{0} + \left\lfloor (y_{1} - y_{0})\frac{\left( x - x_{0} \right)}{\left( x_{1} - x_{0} \right)} \right\rfloor$$ | (B2) |
|---|
Rounding Linear Interpolation Functions
From equations (2) and (3), the rounding result can be characterized by equations (B3) and (B4).
Fixed X-Axis Interpolation Function
$$y = y_{0} + \frac{\left( \left( y_{1} - y_{0} \right)\left( x - x_{0} \right) + \left( \frac{\mathrm{\Delta}x}{2} \right) \right)}{\mathrm{\Delta}x},\ if\ \left( y_{1} - y_{0} \right)\left( x - x_{0} \right) \geq 0$$ $$y = y_{0} + \frac{\left( \left( y_{1} - y_{0} \right)\left( x - x_{0} \right) - \left( \frac{\mathrm{\Delta}x}{2} \right) \right)}{\mathrm{\Delta}x},\ if\ \left( y_{1} - y_{0} \right)\left( x - x_{0} \right) < 0$$ | (B3) |
|---|
Variable X-Axis Interpolation Function
$$y = y_{0} + \frac{\left( \left( y_{1} - y_{0} \right)\left( x - x_{0} \right) + \left( \frac{\left( x_{1} - x_{0} \right)}{2} \right) \right)}{\left( x_{1} - x_{0} \right)},\ if\ \left( y_{1} - y_{0} \right)\left( x - x_{0} \right) \geq 0$$ $$y = y_{0} + \frac{\left( \left( y_{1} - y_{0} \right)\left( x - x_{0} \right) - \left( \frac{\left( x_{1} - x_{0} \right)}{2} \right) \right)}{\left( x_{1} - x_{0} \right)},\ if\ \left( y_{1} - y_{0} \right)\left( x - x_{0} \right) < 0$$ | (B4) |
|---|
Appendix C
The chart below shows the estimated number of clock cycles that are required for the fixed x-axis linear interpolation for various calculation methods. The source file was converted to assembly code for the Renesas RH850 microcontroller targeted for EA4 applications. The number of cycles for each instruction was determined based on the software user’s manual [1]. The best/worst case values are based on all predictive branching passing or failing and all other optimizations are ignored.
Based on the information, use of floating point calculations is too costly in terms of clock cycles for use throughout the project. Where the truncating and rounding functions offer the same results for almost half the execution time.
5.1 - ArchGlbPrm Review
Overview
Summary SheetSynergy Project
Sheet 1: Summary Sheet
Sheet 2: Synergy Project
6.1 - MicroCtrlrSuprt Peer Review Checklists
Overview
Summary SheetSynergy Project
Source Code
PolySpace
Sheet 1: Summary Sheet
Sheet 2: Synergy Project
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: | NxtrMcuSuprtLib.h | Header File Revision: | ||||||||||||||||||||||
| MDD Name: | N/A | Revision: | N/A | |||||||||||||||||||||
| FDD/SCIR/DSR/FDR/CM Name: | N/A | Revision: | N/A | |||||||||||||||||||||
| 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 | N/A | Comments: | No Outputs | |||||||||||||||||||||
| all outputs are initialized prior to being written | ||||||||||||||||||||||||
| Requirements Tracability tags in code match the requirements tracability in the FDD | N/A | Comments: | Nothing to trace to | |||||||||||||||||||||
| requirements tracability in the FDD | ||||||||||||||||||||||||
| 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: | ||||||||||||||||||||||
| and Work CR number | ||||||||||||||||||||||||
| Code accurately implements FDD (Document or Model) | N/A | Comments: | No FDD currently | |||||||||||||||||||||
| Verified no Compiler Errors or 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 | Yes | Comments: | Not needed - assumed caller is passing appropriate pointer addresses | |||||||||||||||||||||
| 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: | No FDD currently available | |||||||||||||||||||||
| 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: | No FDD currently available | |||||||||||||||||||||
| for any FDD corrections needed | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Change Owner: | Lucas Wendling | Review Date : | 10/19/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Kevin Smith | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | Nick Saxton | |||||||||||||||||||||||
Sheet 4: PolySpace
7.1 - MotCtrlMgr Integration Manual
Integration Manual
For
MotCtrlMgr
VERSION: 3
DATE: 09/21/16
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 | Lucas Wendling | 1 | 05/29/15 |
| 2 | Updates for Signal Mapping | Lucas Wendling | 2 | 10/28/15 |
| 3 | Updates describing tool that generates MotCtrlMgr configuration | Lucas Wendling | 3 | 09/21/16 |
Table of Contents
3.2 Global Functions(Non RTE) to be provided to Integration Project 6
4 Configuration REQUIREMeNTS 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
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.00.00 |
| 2 | Software Naming Conventions | Process 04.00.00 |
| 3 | Software Coding Standards | Process 04.00.00 |
| 4 | AR300A_MotCtrlMgr_Design | See Synergy subproject version |
Dependencies
SWCs
| Module | Required Feature |
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
MotCtrlMgrIrq – This is a category 1 interrupt (see details below)
Configuration REQUIREMeNTS
In addition to configuration based .c and .h files, the MotCtrlMgr generator will also generate a .m file data dictionary for MotCtrlMgr. In addition to documentation purposes, this data dictionary is intended to aid in the creation of the AUTOSAR SWC model that is required to be created for the MotCtrlMgr’s signal interface to the RTE. While the generator will create the RTE runnables and runnable contents automatically, the SWC model to be used in the AUTOSAR authoring tools (e.g. Davinci Developer) is not automatically created by the generator and will need either a separate tool to create, or will need to be manually created.
Build Time Config
| Modules | Notes | |
| None |
Configuration Files to be provided by Integration Project
CDD_MotCtrlMgr.c
CDD_MotCtrlMgr_Data.c
CDD_MotCtrlMgr_Data.h
CDD_MotCtrlMgr_Irq.c
DaVinci Parameter Configuration Changes
Most of the configuration parameters in the table below are determined from extracted data from the component data dictionaries of a given project. This includes all of the motor control related runnables as well as all of the signals that interface to motor control related runnables (on either sender or receiver side).
The DataDictionary tool has been updated to support generation of the majority of the MotCtrlMgr configuration listed below. The inputs this tool requires is a project’s collection of component DataDictionaries, a signal mapping xml, as well as the latest FDD tool data management folder. The DataDictionary tool currently generates a .arxml file with all of the MotCtrlMgr configuration except the following parameters which still need to be manually populated:
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/IncludeHeaders
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/SequenceOrder
The DataDictionary tool version which was used for testing of this component is embedded within this component’s baseline. This particular version of the tool is included mostly for reference purposes, and isn’t required to be used at an integration level for the actual generation of the MotCtrlMgr configuration so long as the version that is being used produces the correct output.
| Parameter | Notes | SWC |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/IncludeHeaders | All of the includes that are required to provide runnable prototypes (e.g. “MyHeader.h”) | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable | All of the runnables that are required in a given project that run at the “MotorControl” or “MotorControlx2” Rate. The shortname needs to exactly match the runnable function name | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/RunnableRate | Selection of the rate at which the given runnable executes (MotorControl or MotorControlx2) | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/SequenceOrder | Sequence order number to help define the ordering of the runnables relative to each other. Lower numbers are executed prior to higher numbers. Ordering does not need to be sequential, but it is recommended for clarity. Please note that if all MotorControlx2 runnables are not grouped together, there will be throughput inefficiencies. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/IncludeHeaders | All of the includes that may be required to provide signal initial values (e.g. “MyHeader.h”). This is possibly required if initial values are required to be tied to a global constant that is defined in a certain header for example. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum | All of the enumeration definitions required outside of the RTE. The short name needs to exactly match the desired enumeration name. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumImplementationDataType | Implementation Data Type of the given enumeration. Selection of the supported types of “uint8”, “uint16”, and “uint32”. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumElement | Elements of a given enumeration. The short name should be the enumeration element name. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumElement/Value | Numeric value of a given enumeration element | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping | Contains the configuration required for mapping differently named signals to eachother. This component specifically requires, at a minimum, all of the mapping of names related to signals that flow into, out of, or through the Motor Control runnables. Recommended “Short Name” of container is “<OutputSignal>Map” | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping/OutputSignalName | Output signal name of signal needing mapping | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping/InputSignalName | Input signal name (or names) of signal needing mapping. Note that it is allowed to map more than one input name to each output. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal | Contains the required details of a given signal. The short name should match the base signal name (excluding “MotCtrl” prefix) | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/EnumerationNameReference | Selection of Enumeration (if applicable - this should only exist on signals that are enumerations). Enumeration needs to be added to “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum” configuration before it can be selected. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType | Selection of Implementation Data Type of signal. For enumerations, this should be selected to match the underlying enumeration datatype. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/InitialValue | Initial Value, for arrays this should be a comma separated list (e.g. you would enter: 10,20,30,40). Suffixes of “F”, “U”, etc should be on appropriate signals as required. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Max | Maximum Value as indicated by m file defining signal. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Min | Minimum Value as indicated by m file defining signal. | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable | This flag indicates if a given signal is read in a runnable that runs at “MotorControl” or “MotorControlx2” rate | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable | This flag indicates if a given signal is read in a runnable that runs at 2ms (or slower) RTE task | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable | This flag indicates if a given signal is written in a runnable that runs at “MotorControl” or “MotorControlx2” rate | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable | This flag indicates if a given signal is written in a runnable that runs at 2ms (or slower) RTE task | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size | Size of signal. This needs to be 1 for standard signals and if greater than 1, the signal is considered to be an array | MotCtrlMgr |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Units | Units of signal as indicated by m file defining signal. | MotCtrlMgr |
DaVinci Interrupt Configuration Changes
| ISR Name | Interrupt Category (FE/EI) | Interrupt Channel Number | Priority Dependency | Notes |
| MotCtrlMgrIrq | EI | Needs to be gathered from program specific CM###_XXXXMcuCfg_Design component | Needs to be an appropriate priority for the high speed motor control interrupt | This ISR should be category 1 ISR and mapped to trusted application |
Manual Configuration Changes
| Notes | SWC | |
Integration DATAFLOW REQUIREMENTS
Required Global Data Inputs
This module defines all non-RTE motor control data structures
Required Global Data Outputs
This module defines all non-RTE motor control data structures
Specific Include Path present
Yes
Runnable Scheduling
This section specifies the required runnable scheduling.
| Init | Scheduling Requirements | Trigger |
| Runnable | Scheduling Requirements | Trigger |
| MotCtrlMgrIrq | None | ISR – exact ISR source to be gathered from program specific CM###_XXXXMcuCfg_Design component |
| MotCtrlMgrPer1 | MotCtrlMgrPer1 should execute near the start of the 2ms loop before any other functions that need data that is output by runnables running at the Motor Control rate. The DMA transfer that is populating MotCtrlMgr_TwoMilliSecFromMotCtrl_Rec shall run before MotCtrlMgrPer1 and ideally enough other functionality runs in-between these two events that the transfer can complete with minimal wait time in MotCtrlMgrPer1 (since this function is waiting for DMA transfer completion). | 2ms RTE |
| MotCtrlMgrPer2 | MotCtrlMgrPer2 should execute as the final function of the forward path to allow minimal lag on computation of new PWM commands in the Motor Control loop. | 2ms RTE |
.
Memory Map REQUIREMENTS
Mapping
| Memory Section | Contents | Notes |
| MotCtrl_START_SEC_CODE | Interrupt code | This code section also includes a static function scope variable, and therefore needs to open and close variable mapping statements and this should be mapped to the same application that the ISR is mapped to. |
| CDD_MotCtrlMgr_DmaWrite_START_SEC_VAR_INIT_128 | Data that a DMA channel writes to during run-time | This gets mapped to a “.data_dma_128” section that will need to be explicitly added to the linker file. The intent of this section is to be placed in a RAM memory section that only the DMA has write access to (processor in user mode only has read access). |
* Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.
Usage
| Feature | RAM | ROM |
NvM Blocks
None
Compiler Settings
Preprocessor MACRO
None
Optimization Settings
None
Appendix
<This section is for appendix>
7.2 - MotCtrlMgr Review
Overview
Summary SheetSynergy Project
Davinci Files
PolySpace
Integration Manual
Sheet 1: Summary Sheet
Sheet 2: Synergy Project
Sheet 3: Davinci Files
Sheet 4: PolySpace
Sheet 5: Integration Manual
7.3 - MotCtrlMgr_MDD
Module Design Document
For
MotCtrlMgr
VERSION: 2
DATE: 10/28/15
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 | Lucas Wendling | 1 | 05/29/15 |
| 2 | Updates for Signal Mapping | Lucas Wendling | 2 | 10/28/15 |
Table of Contents
3 MotCtrlMgr High-Level Description 6
4 Design details of software module 7
4.1 Graphical representation of MotCtrlMgr 7
5.1 User defined typedef definition/declaration 8
5.2 Variable definition for enumerated types 8
6.1 Program(fixed) Constants 9
6.1.2 Module specific Lookup Tables Constants 9
7 Software Module Implementation 10
7.1 Generated file description and logic 10
7.2 Initialization Functions 13
7.5.1 Isr: <ModuleName>_Isr<n)> 13
7.6 Serial Communication Functions 14
7.7 Local Function/Macro Definitions 14
7.8 GLObAL Function/Macro Definitions 14
9 Known Limitations With Design 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.00.00 |
| 2 | Software Naming Conventions | Process 04.00.00 |
| 3 | Software Coding Standards | Process 04.00.00 |
| 4 | AR300A_MotCtrlMgr_Design | See Synergy subproject version |
MotCtrlMgr High-Level Description
None
Design details of software module
Graphical representation of MotCtrlMgr
None
Data Flow Diagram
None
Module level DFD
None
Sub-Module level DFD
None
COMPONENT FLOW DIAGRAM
None
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) |
| MotCtrlToTwoMilliSecRec1 | Elements are project specific and generated | struct | ||
| TwoMilliSecFromMotCtrlRec1 | Elements are project specific and generated | struct | ||
| TwoMilliSecToMotCtrlRec1 | Elements are project specific and generated | struct | ||
| MotCtrlFromTwoMilliSecRec1 | Elements are project specific and generated | struct | ||
| MotCtrlIntRec1 | Elements are project specific and generated | struct |
Variable definition for enumerated types
| Enum Name | Element Name | Value |
| Enumerations are project specific and generated |
Constant Data Dictionary
Program(fixed) Constants
Embedded Constants
Local
| Constant Name | Resolution | Units | Value |
| N/A |
Global
| Constant Name |
| N/A |
Module specific Lookup Tables Constants
| Constant Name | Resolution | Value | Software Segment |
| N/A |
Software Module Implementation
Generated file description and logic
The following sections provide details on the logic used for generating the data and functions from the MotCtrlMgr configuration. The generator uses text templating to generate the appropriate file content based on the configuration details. The logic described in the following sections are implemented in the text template files provided in this component.
CDD_MotCtrlMgr_Irq.c
This file contains the definition of the interrupt service routine that Motor Control Manager defines. This interrupt service routine primarily contains a task list for executing runnables that are required to be scheduled at the motor control rate or motor control x2 rate. The following table lists the configuration parameters that are required in generation of this file:
| Configuration Parameter | File Generation Usage Notes |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable | Used to determine the runnables needed to be called in the ISR task list |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/RunnableRate | Used to determine if runnable needs to be called every ISR loop (MotorControl) or every other ISR loop (MotorControlx2) |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/IncludeHeaders | Used for include list required for this file for runnable prototype definitions |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/SequenceOrder | Used to help define the relative calling sequence of the runnables in the ISR task list |
CDD_MotCtrlMgr.c
This file contains the functions for the RTE interface. This file will receive appropriate signals from the RTE and provide appropriate signals to the RTE. Per1 provides updated signals to the RTE after the DMA transfer of the data successfully completed, and Per2 recieves signals from the RTE and then indicates to the DMA that the data is ready for transfer.
| Configuration Parameter | File Generation Usage Notes |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal | Used for the name of the signals being read/written by the runnables being defined. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable | Used in conjuction with “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable” to determine when a signal is needed to be managed by Per1 |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable | Used in conjuction with “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable” to determine when a signal is needed to be managed by Per1 |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable | Used in conjuction with “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable” to determine when a signal is needed to be managed by Per2 |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable | Used in conjuction with “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable” to determine when a signal is needed to be managed by Per2 |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size | Used to determine if the signals being read/written by the runnables being defined are arrays (Impacts RTE API name). |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType | Used to determine if the signals being read/written by the runnables being defined are boolean types (Impacts RTE API name). |
CDD_MotCtrlMgr_Data.c
This file contains the definition of all of the structures containing the Motor Control ISR related signals. This includes providing initial values for all of the signals in the structure and padding the structure for proper structure size alignment restrictions.
| Configuration Parameter | File Generation Usage Notes |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal | Used to determine signal names as part of the logic to determine if special grouping is needed for TSG3 signals |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable | Used to determine which initial values are needed in which structure. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable | Used to determine which initial values are needed in which structure. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable | Used to determine which initial values are needed in which structure. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable | Used to determine which initial values are needed in which structure. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size | Used in the structure size calculation to determine how many pad bytes are needed for alignment at the end of the structure. Used also to add the appropriate braces for arrays on structure elements. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType | Used in the structure size calculation to determine how many pad bytes are needed for alignment at the end of the structure. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/InitialValue | Used as the initializer value for a given signal in the structure |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/IncludeHeaders | Used for include list required for this file for definition of any intial values that may be required |
CDD_MotCtrlMgr_Data.h
This file defines the structure definition of the Motor Control Data structures containing all Motor Control ISR related signals. It also defines any enumerations that need to be accessed by Non-RTE related code. Prototype statements for all Motor Control Data structures are included in this file as well as the macros defined for accessing individual signals of the Motor Control Data structures.
| Configuration Parameter | File Generation Usage Notes |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum | Used to define enumeration accessed by Non-RTE related code. Used for enumeration name. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumImplementationDataType | Used to define enumeration accessed by Non-RTE related code. Used for enumeration datatype. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumElement | Used to define enumeration accessed by Non-RTE related code. Used for enumeration element name. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumElement/Value | Used to define enumeration accessed by Non-RTE related code. Used for enumeration element value. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal | Used to determine signal names as part of the logic to determine if special grouping is needed for TSG3 signals. Also used as signal name for structure element definitions. Used to also determine name of signal access macros that are generated. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable | Used to determine the structure the signal should be added to. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable | Used to determine the structure the signal should be added to |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable | Used to determine the structure the signal should be added to |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable | Used to determine the structure the signal should be added to |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType | Used to determine datatype of structure element. Also used as part of the structure size calculation to determine how many pad bytes are needed for alignment at the end of the structure. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/EnumerationNameReference | Used to determine if a given signal is an enumeration and used to determine the corresponding enumeration name |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size | Used in the structure size calculation to determine how many pad bytes are needed for alignment at the end of the structure. Used also to add the appropriate array size on signals that are arrays (having size > 1). |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping | Used for creation of motor control signal access macros for inputs that are named differently than outputs |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping/OutputSignalName | Output name for signal mapping (used to define an input signal macro definition) |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping/InputSignalName | Input name(s) for signal mapping (used to define the names of the signal macros) |
AR300A_MotCtrlMgr_DataDict.m
This file is the generated data dictionary for MotCtrlMgr. This is intended to be used for documentation purposes as well as to aid in creating the AUTOSAR component description files.
| Configuration Parameter | File Generation Usage Notes |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal | Used to determine signal name for I/O depending on signal useage. |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType | Used to determine datatype of signal. Also used for stripping off c constant qualification (“U”, “L”, “F”) on standard datatypes that is assumed to be present in the initial value. Also used to convert boolean type initial values to “0/1” from “TRUE/FALSE” |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/EnumerationNameReference | Used to determine if a given signal is an enumeration and used to determine the corresponding enumeration name |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/InitialValue | Used for the initial value of a signal |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size | Used to determine if the signal is an array and to set the format of the initial value appropriately |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable | Used to determine if signal is an output from Per1 runnable |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable | Used to determine if signal is an input to Per2 runnable |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Max | Used for Maximum value property of signal |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Min | Used for Minimum value property of signal |
| /Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Units | Used for units property of signal |
Initialization Functions
None
PERIODIC FUNCTIONS
Per1/Per2:
See section 7.1.2
Non PERIODIC FUNCTIONS
None
Interrupt Functions
Isr:
See section 7.1.1
Serial Communication Functions
None
Local Function/Macro Definitions
None
GLObAL Function/Macro Definitions
None
TRANSIENT FUNCTIONS
None
Unit Test Considerations
Known Limitations With Design
None
Appendix
7.4 - MotCtrlMgr DataDictionary Tool User Guide
Purpose
This document provides details on using the DataDictionary.exe tool for generating and testing the MotCtrlMgr component.
Overview
The MotCtrlMgr component is a project specific, highly configurable component. The majority of the configuration parameters of the component, however, can be derived from analysis of the collection of data dictionaries that exist within any given project. A tool was created (DataDictionary.exe) to create a file which contains the bulk of the MotCtrlMgr configuration which can subsequently be imported into the AUTOSAR Configuration Tools (Davinci Configurator). While this tool can primarily be used at a project configuration level, it also is used at a component level in the MotCtrlMgr component. The usage at a component level serves two primary purposes:
Generation of the majority of the MotCtrlMgr “test” configuration.
MotCtrlMgr component defines a “test” configuration. This test configuration is used for several purposes:
To exercise the .bswmd file containing the configuration parameters of MotCtrlMgr (for property correctness and Davinci Configuration compatibility)
To test for the proper/successful generation of the MotCtrlMgr component’s generated configuration files
To generate test files of all generated files of this component used to run static analysis checks on the generated file output, provide the possibility for unit testing of the generated files, and test compilation of the generated files.
Test of the DataDictionary.exe tool output.
Since the DataDictionary.exe tool is used at a project level with files that will change from project to project as needed, it is useful to have a fixed, known set of test files as inputs to the tool to test that the tool is providing the correct output with a known set of inputs. These input files can also be tailored to test different combinations of input scenarios to try to provide a robust set of test inputs to the tool.
Usage Steps for MotCtrlMgr Component Development
Unzip TestDataManagement.zip file into AR300A_MotCtrlMgr_Impl\tools\DataDictionary directory
This is needed since Telelogic synergy can’t currently recognize some of the folder names that are in this directory.
Update Data Dictionary input files in AR300A_MotCtrlMgr_Impl\tools\DataDictionary directory
This step is required if there are new or changed configurations that need to be tested. This step would be manually changing the .m files to add or change the configuration or this could also be done with the aid of matlab data dictionary tools.
Note: if new configurations include new/changed enumerations, these enumerations will need to be manually added into the “TestDataManagement” folder that was unzipped in step 1. And this update will need to be re-zipped for check-in to Synergy.
Note: if the new configurations include new signal mappings, the Mappings.xml file will need to be manually updated in the AR300A_MotCtrlMgr_Impl\tools\DataDictionary directory.
Rerun tool: AR300A_MotCtrlMgr_Impl\tools\DataDictionary\DataDictionary.exe to create new configuration file needed for the next step
Select “Cals” option from initial Data Dictionary tool options:
Select proper tools settings for generation of MotCtrlMgr configuration file. (note file paths may not be exactly the same as listed below):
Select “Generate” option in tool to create MotCtrlMgr.arxml configuration file.
Import MotCtrlMgr.arxml into MotCtrlMgr component Davinci Configurator project.
Notes: It is suggested to remove all configuration containers manually from the old configuration before importing the updated configuration. This allows easier import to ensure that older configuration is fully removed. Otherwise, much more care needs to be taken during the merge process to fully replace older configuration with newer configuration. Additionally, the configuration file does not contain runnable sequence number or header file include needs. These parameters will have to manually be filled out after the import process is complete (or the old configuration settings for these parameters can be kept).
Generate MotCtrlMgr component in Davinci Configurator.
Update Davinci Developer component for any updates needed from configuration changes.
The Davinci Developer component is manually maintained for MotCtrlMgr even though the source code for this component is generated. This component needs to be setup properly for any signals that flow between the MotCtrl Interrupt and RTE tasks. Any changes to Data Dictionary input files (new or changed signals) need to be updated in the Davinci Developer component. As a tip, the component needs to be properly configured to align with the content in AR300A_MotCtrlMgr_Impl\tools\contract\generate\CDD_MotCtrlMgr.c file.
Regenerate RTE contract headers for Davinci Developer component.
This step is done through the Davinci Configurator custom workflow steps that are configured in Davinci Configurator.
8.1 - NxtrDet Integration Manual
Integration Manual
For
NxtrDet
VERSION: 1
DATE: 10/07/15
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 | Lucas Wendling | 1 | 10/07/15 |
Table of Contents
3.2 Global Functions(Non RTE) to be provided to Integration Project 6
4 Configuration REQUIREMeNTS 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
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 – AR998A NxtrDet 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 |
| Det | Entire Module – NxtrDet is a component that manages the Det errors that are defined by Nexteer SWCs. The AUTOSAR Det module is required for NxtrDet functionality. |
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
NxtrDet functionality defaults in a manner in which it will automatically enable all of the defined Nexteer Det errors when the global Det Enable flag is turned on. It is assumed that as needed, a project could selectively disable certain Nexteer Det errors if needed, but this currently would have to be managed either by alteration of the NxtrDet.h component header directly for the Det enabled build, or by an integration project pointing to its own integration specific version of NxtrDet.h.
Build Time Config
| Modules | Notes | |
| None |
Configuration Files to be provided by Integration Project
Da Vinci Parameter Configuration Changes
| Parameter | Notes | SWC |
DaVinci Interrupt Configuration Changes
| ISR Name | VIM # | Priority Dependency | Notes |
Manual Configuration Changes
| Constant | Notes | SWC |
| None |
Integration DATAFLOW REQUIREMENTS
Required Global Data Inputs
None
Required Global Data Outputs
None
Specific Include Path present
Yes
Runnable Scheduling
This section specifies the required runnable scheduling.
| Init | Scheduling Requirements | Trigger |
| None |
| Runnable | Scheduling Requirements | Trigger |
| None |
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
*See DataDict.m
Compiler Settings
Preprocessor MACRO
None
Optimization Settings
None
Appendix
<This section is for appendix>
8.2 - NxtrDet Module Design Document
Module Design Document
For
NxtrDet
Oct 6, 2015
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 | Lucas Wendling | 1 | 10/06/15 |
Table of Contents
2 NxtrDet High-Level Description 5
3 Design details of software module 6
3.1 Graphical representation of NxtrDet 6
4.1 Program (fixed) Constants 7
5 Software Component Implementation 8
5.4 Module Internal (Local) Functions 8
5.5 GLOBAL Function/Macro Definitions 8
6 Known Limitations with Design 10
Appendix A Abbreviations and Acronyms 12
Introduction
Purpose
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.
NxtrDet High-Level Description
See FDD
Design details of software module
Graphical representation of NxtrDet
None
Data Flow Diagram
Component level DFD
N/A
Function level DFD
N/A
Constant Data Dictionary
Program (fixed) Constants
Embedded Constants
Constants containing the Nexteer ModuleIDs defined for Det functionality are defined in the .m file included in the doc folder of this component. This is to allow new SWCs adding new Det errors to not drive changes to the design project, only to the implementation project.
Local Constants
| Constant Name | Resolution | Units | Value |
|---|---|---|---|
| None |
Software Component Implementation
Sub-Module Functions
Init: NxtrDet
None
Per: NxtrDet
None
Server Runables
None
Interrupt Functions
None
Module Internal (Local) Functions
Local 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 |
Design Rationale
Processing
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 |
Design Rationale
Processing
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 |
8.3 - NxtrDet Peer Review Checklists
Overview
Summary SheetSynergy Project
Source Code
PolySpace
Sheet 1: Summary Sheet
Sheet 2: Synergy Project
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: | NxtrDet.h | Header File Revision: | ||||||||||||||||||||||
| MDD Name: | NxtrDet Module Design Document | Revision: | 1 | |||||||||||||||||||||
| FDD/SCIR/DSR/FDR/CM Name: | AR998A_NxtrDet_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 | N/A | Comments: | ||||||||||||||||||||||
| for constant names | Yes | Comments: | ||||||||||||||||||||||
| for function names | N/A | Comments: | ||||||||||||||||||||||
| for other names (component, memory | Yes | Comments: | ||||||||||||||||||||||
| mapping handles, typedefs, etc.) | ||||||||||||||||||||||||
| All paths assign a value to outputs, ensuring | 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 | 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 | 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 | Yes | Comments: | ||||||||||||||||||||||
| "magic numbers": [N12] | ||||||||||||||||||||||||
| Memory mapping for non-RTE code | N/A | Comments: | ||||||||||||||||||||||
| is per standard | ||||||||||||||||||||||||
| All execution-order-dependent code can be | N/A | Comments: | ||||||||||||||||||||||
| recognized by the compiler: [N80] | ||||||||||||||||||||||||
| All loops have termination conditions that ensure | N/A | Comments: | ||||||||||||||||||||||
| finite loop iterations: [N63] | ||||||||||||||||||||||||
| All divides protect against divide by zero | N/A | Comments: | ||||||||||||||||||||||
| if needed: [N65] | ||||||||||||||||||||||||
| All integer division and modulus operations | N/A | Comments: | ||||||||||||||||||||||
| handle negative numbers correctly: [N76] | ||||||||||||||||||||||||
| All typecasting and fixed point arithmetic, | N/A | Comments: | ||||||||||||||||||||||
| including all use of fixed point macros and | ||||||||||||||||||||||||
| timer functions, is correct and has no possibility | ||||||||||||||||||||||||
| of unintended overflow or underflow: [N66] | ||||||||||||||||||||||||
| All float-to-unsiged conversions ensure the. | N/A | Comments: | ||||||||||||||||||||||
| float value is non-negative: [N67] | ||||||||||||||||||||||||
| All conversions between signed and unsigned | N/A | Comments: | ||||||||||||||||||||||
| types handle msb==1 as intended: [N78] | ||||||||||||||||||||||||
| All pointer dereferencing protects against | N/A | Comments: | ||||||||||||||||||||||
| null pointer if needed: [N70] | ||||||||||||||||||||||||
| Component outputs are limited to the legal range | N/A | Comments: | ||||||||||||||||||||||
| defined in the FDD DataDict.m file : [N53] | ||||||||||||||||||||||||
| All code is mapped with FDD (all FDD | 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: | ||||||||||||||||||||||||
| Header file only | ||||||||||||||||||||||||
| Change Owner: | Spandana Balani | Review Date : | 03/11/16 | |||||||||||||||||||||
| Lead Peer Reviewer: | Jared Julian | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | Luke | Kathleen | ||||||||||||||||||||||
Sheet 4: PolySpace
9.1 - NxtrFil Integration Manual
Integration Manual
For
NxtrFil
VERSION: 1.0
DATE: 03/02/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 | K. Creager | 1.0 | 03/02/15 |
Table of Contents
3.2 Global Functions(Non RTE) to be provided to Integration Project 6
4 Configuration REQUIREMeNTS 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
Abbrevations And Acronyms
| Abbreviation | Description |
References
This section lists the title & version of all the documents that are referred for development of this document
| Sr. No. | Title | Version |
| 1 | Working EA4 naming Conventions[1] | Temp |
| 2 | AutoSAR and Nexteer KeyWord Abbreviations list[1] | Temp |
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
FilLpUpdGain()
FilLpUpdOutp_f32()
FilLpInit()
FilHpUpdGain()
FilHpUpdOutp_f32()
FilHpInit()
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
N/A
Required Global Data Outputs
N/A
Specific Include Path present
Yes
Runnable Scheduling
This section specifies the required runnable scheduling.
| Init | Scheduling Requirements | Trigger |
| None | None | RTE/ISR(<time>ms) |
| Runnable | Scheduling Requirements | Trigger |
| None | None | RTE/ISR(<time>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
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
[1] – No official document released for EA4.0 for this document’s revision.
9.2 - NxtrFil Review
Overview
Summary SheetSource Code - initial review
Source Code -rework review
QAC - initial review
QAC - rework review
Integration Manual
Sheet 1: Summary Sheet
Sheet 2: Source Code - initial review
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (Source Code Review) | ||||||||||||||||||||||||
| Source File Name: | Source File Revision: | |||||||||||||||||||||||
| Module Design Document Name: | MDD Revision: | |||||||||||||||||||||||
| Data Dictionary Revision: | FDD/SER/CMS | |||||||||||||||||||||||
| and Revision: | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | Software Naming Convention V1.2 followed: | |||||||||||||||||||||||
| for variable names | X | Comments: | EA4 naming conventions | |||||||||||||||||||||
| for constant names | X | Comments: | EA4 naming conventions | |||||||||||||||||||||
| for function names | X | Comments: | add _f32 to functions that return float32 | |||||||||||||||||||||
| for other names (component, memory | X | Comments: | memory names need NxtrFil instead of NXTRFIL | |||||||||||||||||||||
| mapping handles, typedefs, etc.) | ||||||||||||||||||||||||
| All buffered outputs written in every path, i.e. no | X | Comments: | N/A | |||||||||||||||||||||
| possibility of an uninitialized value being written | ||||||||||||||||||||||||
| Group-review Checklist (review board) | Synergy version matches change history | X | Comments: | |||||||||||||||||||||
| and Version Control version in file comment block | ||||||||||||||||||||||||
| Change log contains detailed description of changes | X | Comments: | ||||||||||||||||||||||
| and CR number | ||||||||||||||||||||||||
| Code accurately implements FDD (Document or Model) | X | Comments: | FDD not created yet | |||||||||||||||||||||
| implementation matches EA3 macro implementation | ||||||||||||||||||||||||
| No Compiler Errors or Warnings verified | X | Comments: | ||||||||||||||||||||||
| FDD test points exist as display variables: declared | X | Comments: | N/A | |||||||||||||||||||||
| static volatile, written once and never used, names | ||||||||||||||||||||||||
| match the FDD | ||||||||||||||||||||||||
| Software Design and Coding Standards V2.0 followed: | ||||||||||||||||||||||||
| Code comments are clear, correct, and adequate | X | 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 | X | Comments: | ||||||||||||||||||||||
| standards and contain correct information: [N41], [N42] | ||||||||||||||||||||||||
| Function comment blocks are per standards and | X | Comments: | ||||||||||||||||||||||
| contain correct information: [N43] | ||||||||||||||||||||||||
| Code formatting (indentation, placement of | X | Comments: | ||||||||||||||||||||||
| braces, etc.) is per standards: [N5], [N55], [N56], | ||||||||||||||||||||||||
| [N57], [N58], [N59] | ||||||||||||||||||||||||
| Embedded constants used per standards; no | X | Comments: | ||||||||||||||||||||||
| "magic numbers": [N12] | ||||||||||||||||||||||||
| All variables and constants defined at module | X | Comments: | N/A | |||||||||||||||||||||
| level are included in appropriate MemMap | ||||||||||||||||||||||||
| section: [N25] and Naming Conventions | ||||||||||||||||||||||||
| All execution-order-dependent code can be | X | Comments: | N/A | |||||||||||||||||||||
| recognized by the compiler: [N80] | ||||||||||||||||||||||||
| No possibility of a non-terminating loop: [N63] | X | Comments: | N/A | |||||||||||||||||||||
| No possibility of divide by zero: [N65] | X | Comments: | logic prevents divide by zero | |||||||||||||||||||||
| All integer division and modulus operations | X | Comments: | N/A | |||||||||||||||||||||
| handle negative numbers correctly: [N76] | ||||||||||||||||||||||||
| All typecasting and fixed point arithmetic, | X | Comments: | N/A | |||||||||||||||||||||
| including all use of fixed point macros and | ||||||||||||||||||||||||
| timer functions, is correct and has no possibility | ||||||||||||||||||||||||
| of unintended overflow or underflow: [N66] | ||||||||||||||||||||||||
| No possibility of converting a negative floating | X | Comments: | N/A | |||||||||||||||||||||
| point value to an unsigned type: [N67] | ||||||||||||||||||||||||
| All conversions between signed and unsigned | X | Comments: | N/A | |||||||||||||||||||||
| types handle msb==1 as intended: [N78] | ||||||||||||||||||||||||
| No possibility of dereferencing a null | X | Comments: | design limitation - pointer parameters | |||||||||||||||||||||
| pointer: [N70] | must have non-null values | |||||||||||||||||||||||
| Global outputs (RTE and Non-RTE) Initialized: | X | Comments: | N/A | |||||||||||||||||||||
| [N24] | ||||||||||||||||||||||||
| Module outputs are limited to the legal range | X | Comments: | N/A | |||||||||||||||||||||
| defined in the FDD Data dictionary: [N53] | ||||||||||||||||||||||||
| All code is mapped with FDD (all FDD | X | Comments: | to be added in later rev, after FDD and | |||||||||||||||||||||
| subfunctions and/or model blocks identified | FRs are created | |||||||||||||||||||||||
| with code comments; all code corresponds to | ||||||||||||||||||||||||
| some FDD subfunction and/or model block): [N40] | ||||||||||||||||||||||||
| Struct types used for NvM have | X | Comments: | N/A | |||||||||||||||||||||
| elements declared in decreasing order by size | ||||||||||||||||||||||||
| and are not nested or used in arrays: [N84], [N85] | ||||||||||||||||||||||||
| No violations of other coding standard rules | X | Comments: | ||||||||||||||||||||||
| identified during review | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Change Owner: | Kathleen Creager | Review Date : | 02/27/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Kevin Smith | Approved by Reviewer(s): | ||||||||||||||||||||||
| Other Reviewer(s): | Lucas Wendling | |||||||||||||||||||||||
Sheet 3: Source Code -rework review
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (Source Code Review) | ||||||||||||||||||||||||
| Source File Name: | Source File Revision: | |||||||||||||||||||||||
| Module Design Document Name: | MDD Revision: | |||||||||||||||||||||||
| Data Dictionary Revision: | FDD/SER/CMS | |||||||||||||||||||||||
| and Revision: | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | Software Naming Convention V1.2 followed: | |||||||||||||||||||||||
| for variable names | X | Comments: | EA4 naming conventions | |||||||||||||||||||||
| for constant names | X | Comments: | EA4 naming conventions | |||||||||||||||||||||
| for function names | X | Comments: | ||||||||||||||||||||||
| for other names (component, memory | X | Comments: | ||||||||||||||||||||||
| mapping handles, typedefs, etc.) | ||||||||||||||||||||||||
| All buffered outputs written in every path, i.e. no | X | Comments: | N/A | |||||||||||||||||||||
| possibility of an uninitialized value being written | ||||||||||||||||||||||||
| Group-review Checklist (review board) | Synergy version matches change history | X | Comments: | |||||||||||||||||||||
| and Version Control version in file comment block | ||||||||||||||||||||||||
| Change log contains detailed description of changes | X | Comments: | ||||||||||||||||||||||
| and CR number | ||||||||||||||||||||||||
| Code accurately implements FDD (Document or Model) | X | Comments: | FDD not created yet | |||||||||||||||||||||
| implementation matches EA3 macro implementation | ||||||||||||||||||||||||
| No Compiler Errors or Warnings verified | X | Comments: | ||||||||||||||||||||||
| FDD test points exist as display variables: declared | X | Comments: | N/A | |||||||||||||||||||||
| static volatile, written once and never used, names | ||||||||||||||||||||||||
| match the FDD | ||||||||||||||||||||||||
| Software Design and Coding Standards V2.0 followed: | ||||||||||||||||||||||||
| Code comments are clear, correct, and adequate | X | 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 | X | Comments: | ||||||||||||||||||||||
| standards and contain correct information: [N41], [N42] | ||||||||||||||||||||||||
| Function comment blocks are per standards and | X | Comments: | ||||||||||||||||||||||
| contain correct information: [N43] | ||||||||||||||||||||||||
| Code formatting (indentation, placement of | X | Comments: | ||||||||||||||||||||||
| braces, etc.) is per standards: [N5], [N55], [N56], | ||||||||||||||||||||||||
| [N57], [N58], [N59] | ||||||||||||||||||||||||
| Embedded constants used per standards; no | X | Comments: | ||||||||||||||||||||||
| "magic numbers": [N12] | ||||||||||||||||||||||||
| All variables and constants defined at module | X | Comments: | N/A | |||||||||||||||||||||
| level are included in appropriate MemMap | ||||||||||||||||||||||||
| section: [N25] and Naming Conventions | ||||||||||||||||||||||||
| All execution-order-dependent code can be | X | Comments: | N/A | |||||||||||||||||||||
| recognized by the compiler: [N80] | ||||||||||||||||||||||||
| No possibility of a non-terminating loop: [N63] | X | Comments: | N/A | |||||||||||||||||||||
| No possibility of divide by zero: [N65] | X | Comments: | logic prevents divide by zero | |||||||||||||||||||||
| All integer division and modulus operations | X | Comments: | N/A | |||||||||||||||||||||
| handle negative numbers correctly: [N76] | ||||||||||||||||||||||||
| All typecasting and fixed point arithmetic, | X | Comments: | N/A | |||||||||||||||||||||
| including all use of fixed point macros and | ||||||||||||||||||||||||
| timer functions, is correct and has no possibility | ||||||||||||||||||||||||
| of unintended overflow or underflow: [N66] | ||||||||||||||||||||||||
| No possibility of converting a negative floating | X | Comments: | N/A | |||||||||||||||||||||
| point value to an unsigned type: [N67] | ||||||||||||||||||||||||
| All conversions between signed and unsigned | X | Comments: | N/A | |||||||||||||||||||||
| types handle msb==1 as intended: [N78] | ||||||||||||||||||||||||
| No possibility of dereferencing a null | X | Comments: | documented in usage notes | |||||||||||||||||||||
| pointer: [N70] | no run-time check for throughput reasons | |||||||||||||||||||||||
| Global outputs (RTE and Non-RTE) Initialized: | X | Comments: | N/A | |||||||||||||||||||||
| [N24] | ||||||||||||||||||||||||
| Module outputs are limited to the legal range | X | Comments: | N/A | |||||||||||||||||||||
| defined in the FDD Data dictionary: [N53] | ||||||||||||||||||||||||
| All code is mapped with FDD (all FDD | X | Comments: | to be added in later rev, after FDD and | |||||||||||||||||||||
| subfunctions and/or model blocks identified | FRs are created | |||||||||||||||||||||||
| with code comments; all code corresponds to | ||||||||||||||||||||||||
| some FDD subfunction and/or model block): [N40] | ||||||||||||||||||||||||
| Struct types used for NvM have | X | Comments: | N/A | |||||||||||||||||||||
| elements declared in decreasing order by size | ||||||||||||||||||||||||
| and are not nested or used in arrays: [N84], [N85] | ||||||||||||||||||||||||
| No violations of other coding standard rules | X | Comments: | ||||||||||||||||||||||
| identified during review | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| reviewed after rework from initial review (rework done: _f32 added to function names of functions that return float32; capitalization corrected on memory mapping | ||||||||||||||||||||||||
| names; design limitation regarding no checking for null pointers added as usage note in function comment blocks, to be added to design component when created) | ||||||||||||||||||||||||
| Change Owner: | Kathleen Creager | Review Date : | 03/03/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Kevin Smith | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | ||||||||||||||||||||||||
Sheet 4: QAC - initial review
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (QAC Review) | ||||||||||||||||||||||||
| Module Name: | Source File Revision: | 1 | Module | 1 | of | 1 | ||||||||||||||||||
| Compliance Guidelines Version: | EA4 working | |||||||||||||||||||||||
| Used NxtrFil_TestHarness.c (in tools folder) for QAC and Polyspace analysis of the NxtrFil.h file. | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | QAC version is correct and did not change (List version) | X | Comments: | 1.0.0 | ||||||||||||||||||||
| component-specific QAC and Polyspace files needed | ||||||||||||||||||||||||
| in order to see warnings on this library header file | ||||||||||||||||||||||||
| (see tools folder) | ||||||||||||||||||||||||
| Contract Folder's header files are appropriate | X | Comments: | needs rework due to function name changes | |||||||||||||||||||||
| Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Guidelines | X | Comments: | Polyspace gives MISRA warning 21.1 | ||||||||||||||||||||
| for possible null pointer dereference; see comments below | ||||||||||||||||||||||||
| Cyclomatic complexity and Static path count ok per | X | Comments: | ||||||||||||||||||||||
| Design and Coding Standards rule [N47] | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| waiting for Polyspace guidelines before using deviation comments for Polyspace-only MISRA warnings. The null pointer warning should not show up when running | ||||||||||||||||||||||||
| Polyspace on an integration project. | ||||||||||||||||||||||||
| Change Owner: | Kathleen Creager | Review Date : | 02/27/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Kevin Smith | Approved by Reviewer(s): | ||||||||||||||||||||||
| Other Reviewer(s): | Lucas Wendling | |||||||||||||||||||||||
Sheet 5: QAC - rework review
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (QAC Review) | ||||||||||||||||||||||||
| Module Name: | Source File Revision: | 1 | Module | 1 | of | 1 | ||||||||||||||||||
| Compliance Guidelines Version: | EA4 working | |||||||||||||||||||||||
| Used NxtrFil_TestHarness.c (in tools folder) for QAC and Polyspace analysis of the NxtrFil.h file. | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | QAC version is correct and did not change (List version) | X | Comments: | 1.0.0 | ||||||||||||||||||||
| component-specific QAC and Polyspace files needed | ||||||||||||||||||||||||
| in order to see warnings on this library header file | ||||||||||||||||||||||||
| (see tools folder) | ||||||||||||||||||||||||
| Contract Folder's header files are appropriate | X | Comments: | ||||||||||||||||||||||
| Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Guidelines | X | Comments: | Polyspace gives MISRA warning 21.1 | ||||||||||||||||||||
| for possible null pointer dereference; see comments below | ||||||||||||||||||||||||
| Cyclomatic complexity and Static path count ok per | X | Comments: | ||||||||||||||||||||||
| Design and Coding Standards rule [N47] | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| re-run and re-reviewed after source code and contract folder file rework from initial review | ||||||||||||||||||||||||
| waiting for Polyspace guidelines before using deviation comments for Polyspace-only MISRA warnings. The null pointer warning should not show up when running | ||||||||||||||||||||||||
| Polyspace on an integration project. Usaage notes in function comment blocks document the design limitation. | ||||||||||||||||||||||||
| Change Owner: | Kathleen Creager | Review Date : | 03/03/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Kevin Smith | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | ||||||||||||||||||||||||
Sheet 6: Integration Manual
10.1 - NxtrFixdPt Integration Manual
Integration Manual
For
NxtrFixdPt
VERSION: 1.2
DATE: 13/02/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 | Selva Sengottaiyan | 1.0 | 02/13/15 |
Table of Contents
3.2 Global Functions(Non RTE) to be provided to Integration Project 6
4 Configuration REQUIREMeNTS 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
Abbrevations And Acronyms
| Abbreviation | Description |
References
This section lists the title & version of all the documents that are referred for development of this document
| Sr. No. | Title | Version |
| 1 | Working EA4 naming Conventions[1] | Temp |
| 2 | AutoSAR and Nexteer KeyWord Abbreviations list[1] | Temp |
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
FloatToFixdWithRound_s16_f32()
FloatToFixdWithRound_s32_f32()
FloatToFixdWithRound_u16_f32()
FloatToFixdWithRound_u32_f32()
FloatToFixd_s16_f32()
FloatToFixd_s32_f32()
FloatToFixd_u16_f32()
FloatToFixd_u32_f32()
FixdToFloat_f32_s16()
FixdToFloat_f32_s32()
FixdToFloat_f32_u16()
FixdToFloat_f32_u32()
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
N/A
Required Global Data Outputs
N/A
Specific Include Path present
Yes
Runnable Scheduling
This section specifies the required runnable scheduling.
| Init | Scheduling Requirements | Trigger |
| None | None | RTE/ISR(<time>ms) |
| Runnable | Scheduling Requirements | Trigger |
| None | None | RTE/ISR(<time>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
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
[1] – No official document released for EA4.0.
10.2 - NxtrFixdPt Review
Overview
Summary SheetSource Code
QAC
Integration Manual
Sheet 1: Summary Sheet
Sheet 2: Source Code
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (Source Code Review) | ||||||||||||||||||||||||
| Source File Name: | Source File Revision: | |||||||||||||||||||||||
| Module Design Document Name: | MDD Revision: | |||||||||||||||||||||||
| Data Dictionary Revision: | FDD/SER/CMS | |||||||||||||||||||||||
| and Revision: | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | Software Naming Convention V1.2 followed: | |||||||||||||||||||||||
| for variable names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for constant names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for function names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for other names (component, memory | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| mapping handles, typedefs, etc.) | ||||||||||||||||||||||||
| All buffered outputs written in every path, i.e. no | X | Comments: N/A | ||||||||||||||||||||||
| possibility of an uninitialized value being written | ||||||||||||||||||||||||
| Group-review Checklist (review board) | Synergy version matches change history | Comments: | ||||||||||||||||||||||
| and Version Control version in file comment block | ||||||||||||||||||||||||
| Change log contains detailed description of changes | X | Comments: | ||||||||||||||||||||||
| and CR number | ||||||||||||||||||||||||
| Code accurately implements FDD (Document or Model) | X | Comments: | No FDD Currently Available | |||||||||||||||||||||
| No Compiler Errors or Warnings verified | X | Comments: | Component only has header file | |||||||||||||||||||||
| FDD test points exist as display variables: declared | X | Comments: N/A | ||||||||||||||||||||||
| static volatile, written once and never used, names | ||||||||||||||||||||||||
| match the FDD | ||||||||||||||||||||||||
| Software Design and Coding Standards V2.0 followed: | ||||||||||||||||||||||||
| Code comments are clear, correct, and adequate | X | 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 | X | Comments: | ||||||||||||||||||||||
| standards and contain correct information: [N41], [N42] | ||||||||||||||||||||||||
| Function comment blocks are per standards and | X | Comments: | ||||||||||||||||||||||
| contain correct information: [N43] | ||||||||||||||||||||||||
| Code formatting (indentation, placement of | X | Comments: | ||||||||||||||||||||||
| braces, etc.) is per standards: [N5], [N55], [N56], | ||||||||||||||||||||||||
| [N57], [N58], [N59] | ||||||||||||||||||||||||
| Embedded constants used per standards; no | X | Comments: | ||||||||||||||||||||||
| "magic numbers": [N12] | ||||||||||||||||||||||||
| All variables and constants defined at module | X | Comments: N/A for inline functions | ||||||||||||||||||||||
| level are included in appropriate MemMap | ||||||||||||||||||||||||
| section: [N25] and Naming Conventions | ||||||||||||||||||||||||
| All execution-order-dependent code can be | X | Comments: | N/A | |||||||||||||||||||||
| recognized by the compiler: [N80] | ||||||||||||||||||||||||
| No possibility of a non-terminating loop: [N63] | X | Comments: | N/A | |||||||||||||||||||||
| No possibility of divide by zero: [N65] | X | Comments: | N/A | |||||||||||||||||||||
| All integer division and modulus operations | X | Comments: | ||||||||||||||||||||||
| handle negative numbers correctly: [N76] | ||||||||||||||||||||||||
| All typecasting and fixed point arithmetic, | X | Comments: | ||||||||||||||||||||||
| including all use of fixed point macros and | ||||||||||||||||||||||||
| timer functions, is correct and has no possibility | ||||||||||||||||||||||||
| of unintended overflow or underflow: [N66] | ||||||||||||||||||||||||
| No possibility of converting a negative floating | X | Comments: | If the input arguments are not followed based on the rules. There is possibility for unexpected results | |||||||||||||||||||||
| point value to an unsigned type: [N67] | ||||||||||||||||||||||||
| All conversions between signed and unsigned | X | Comments: | ||||||||||||||||||||||
| types handle msb==1 as intended: [N78] | ||||||||||||||||||||||||
| No possibility of dereferencing a null | X | Comments: N/A | ||||||||||||||||||||||
| pointer: [N70] | ||||||||||||||||||||||||
| Global outputs (RTE and Non-RTE) Initialized: | X | Comments: N/A | ||||||||||||||||||||||
| [N24] | ||||||||||||||||||||||||
| Module outputs are limited to the legal range | X | Comments: N/A | ||||||||||||||||||||||
| defined in the FDD Data dictionary: [N53] | ||||||||||||||||||||||||
| All code is mapped with FDD (all FDD | X | Comments: No FDD Available | ||||||||||||||||||||||
| subfunctions and/or model blocks identified | ||||||||||||||||||||||||
| with code comments; all code corresponds to | ||||||||||||||||||||||||
| some FDD subfunction and/or model block): [N40] | ||||||||||||||||||||||||
| Struct types used for NvM have | X | Comments: N/A | ||||||||||||||||||||||
| elements declared in decreasing order by size | ||||||||||||||||||||||||
| and are not nested or used in arrays: [N84], [N85] | ||||||||||||||||||||||||
| No violations of other coding standard rules | X | Comments: | ||||||||||||||||||||||
| identified during review | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Change Owner: | Selva Sengottaiyan | Review Date : | 02/13/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Kevin Smith | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | Lucas Wendling | Kathleen Creager | ||||||||||||||||||||||
Sheet 3: QAC
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (QAC Review) | ||||||||||||||||||||||||
| Module Name: | Source File Revision: | 1 | Module | 1 | of | 1 | ||||||||||||||||||
| Compliance Guidelines Version: | N/A | |||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | QAC version is correct and did not change (List version) | X | Comments: | Using working EA4 version plus special analyzer file which was reviewed | ||||||||||||||||||||
| Contract Folder's header files are appropriate | X | Comments: | ||||||||||||||||||||||
| Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Guidelines | X | Comments: | Approved deviations for 8.5 and 1.1 | ||||||||||||||||||||
| Cyclomatic complexity and Static path count ok per | X | Comments: | ||||||||||||||||||||||
| Design and Coding Standards rule [N47] | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Change Owner: | Selva Sengottaiyan | Review Date : | 02/13/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Kevin Smith | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | ||||||||||||||||||||||||
Sheet 4: Integration Manual
11.1 - NxtrIntrpn Integration Manual
Integration Manual
For
NxtrIntrpn
VERSION: 1.0
DATE: 02/19/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 | K. Smith | 1.0 | 02/19/15 |
Table of Contents
3.2 Global Functions(Non RTE) to be provided to Integration Project 6
4 Configuration REQUIREMeNTS 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
Abbrevations And Acronyms
| Abbreviation | Description |
References
This section lists the title & version of all the documents that are referred for development of this document
| Sr. No. | Title | Version |
| 1 | Working EA4 naming Conventions[1] | Temp |
| 2 | AutoSAR and Nexteer KeyWord Abbreviations list[1] | Temp |
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
LnrIntrpn_u16_u16FixdXu16VariY()
LnrIntrpn_s16_u16FixdXs16VariY()
LnrIntrpn_u16_u16VariXu16VariY()
LnrIntrpn_u16_s16VariXu16VariY()
LnrIntrpn_s16_s16VariXs16VariY()
LnrIntrpn_s16_u16VariXs16VariY()
LnrIntrpnWithRound_u16_u16FixdXu16VariY()
LnrIntrpnWithRound_s16_u16FixdXs16VariY()
LnrIntrpnWithRound_u16_u16VariXu16VariY()
LnrIntrpnWithRound_u16_s16VariXu16VariY()
LnrIntrpnWithRound_s16_s16VariXs16VariY()
LnrIntrpnWithRound_s16_u16VariXs16VariY()
BilnrIntrpnWithRount_u16_u16CmnXu16MplY()
BilnrIntrpnWithRound_s16_u16CmnXs16MplY()
BilnrIntrpnWithRound_s16_s16CmnXs16MplY()
BilnrIntrpnWithRound_u16_s16CmnXu16MplY()
BilnrIntrpnWithRound_s16_u16MplXs16MplY()
BilnrIntrpnWithRound_s16_s16MplXs16MplY()
BilnrIntrpnWithRound_u16_u16MplXu16MplY()
BilnrIntrpnWithRound_u16_s16MplXu16MplY()
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
N/A
Required Global Data Outputs
N/A
Specific Include Path present
Yes
Runnable Scheduling
This section specifies the required runnable scheduling.
| Init | Scheduling Requirements | Trigger |
| None | None | RTE/ISR(<time>ms) |
| Runnable | Scheduling Requirements | Trigger |
| None | None | RTE/ISR(<time>ms) |
.
Memory Map REQUIREMENTS
Mapping
| Memory Section | Contents | Notes |
| None | ||
| NxtrIntrpn_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
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
[1] – No official document released for EA4.0 for this document’s revision.
11.2 - NxtrIntrpn Review
Overview
Summary SheetSource Code
QAC
Integration Manual
Sheet 1: Summary Sheet
Sheet 2: Source Code
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (Source Code Review) | ||||||||||||||||||||||||
| Source File Name: | Source File Revision: | |||||||||||||||||||||||
| Module Design Document Name: | MDD Revision: | |||||||||||||||||||||||
| Data Dictionary Revision: | FDD/SER/CMS | |||||||||||||||||||||||
| and Revision: | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | Software Naming Convention V1.2 followed: | |||||||||||||||||||||||
| for variable names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for constant names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for function names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for other names (component, memory | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| mapping handles, typedefs, etc.) | ||||||||||||||||||||||||
| All buffered outputs written in every path, i.e. no | X | Comments: N/A | ||||||||||||||||||||||
| possibility of an uninitialized value being written | ||||||||||||||||||||||||
| Group-review Checklist (review board) | Synergy version matches change history | X | Comments: | |||||||||||||||||||||
| and Version Control version in file comment block | ||||||||||||||||||||||||
| Change log contains detailed description of changes | X | Comments: | ||||||||||||||||||||||
| and CR number | ||||||||||||||||||||||||
| Code accurately implements FDD (Document or Model) | X | Comments: | Code is implemented to execute the | |||||||||||||||||||||
| equation(s) defined in the FDD. | ||||||||||||||||||||||||
| No Compiler Errors or Warnings verified | X | Comments: | ||||||||||||||||||||||
| FDD test points exist as display variables: declared | X | Comments: N/A | ||||||||||||||||||||||
| static volatile, written once and never used, names | ||||||||||||||||||||||||
| match the FDD | ||||||||||||||||||||||||
| Software Design and Coding Standards V2.0 followed: | ||||||||||||||||||||||||
| Code comments are clear, correct, and adequate | X | 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 | X | Comments: | ||||||||||||||||||||||
| standards and contain correct information: [N41], [N42] | ||||||||||||||||||||||||
| Function comment blocks are per standards and | X | Comments: | ||||||||||||||||||||||
| contain correct information: [N43] | ||||||||||||||||||||||||
| Code formatting (indentation, placement of | X | Comments: | ||||||||||||||||||||||
| braces, etc.) is per standards: [N5], [N55], [N56], | ||||||||||||||||||||||||
| [N57], [N58], [N59] | ||||||||||||||||||||||||
| Embedded constants used per standards; no | X | Comments: | N/A | |||||||||||||||||||||
| "magic numbers": [N12] | ||||||||||||||||||||||||
| All variables and constants defined at module | X | Comments: | N/A | |||||||||||||||||||||
| level are included in appropriate MemMap | ||||||||||||||||||||||||
| section: [N25] and Naming Conventions | ||||||||||||||||||||||||
| All execution-order-dependent code can be | X | Comments: | N/A | |||||||||||||||||||||
| recognized by the compiler: [N80] | ||||||||||||||||||||||||
| No possibility of a non-terminating loop: [N63] | X | Comments: | N/A | |||||||||||||||||||||
| No possibility of divide by zero: [N65] | X | Comments: | Code protects for this by the boundary | |||||||||||||||||||||
| checking that is in place. Otherwise no direct prevention is | ||||||||||||||||||||||||
| implemented. | ||||||||||||||||||||||||
| All integer division and modulus operations | X | Comments: | Limitations in design are documented | |||||||||||||||||||||
| handle negative numbers correctly: [N76] | in the FDD | |||||||||||||||||||||||
| All typecasting and fixed point arithmetic, | X | Comments: | ||||||||||||||||||||||
| including all use of fixed point macros and | ||||||||||||||||||||||||
| timer functions, is correct and has no possibility | ||||||||||||||||||||||||
| of unintended overflow or underflow: [N66] | ||||||||||||||||||||||||
| No possibility of converting a negative floating | X | Comments: | ||||||||||||||||||||||
| point value to an unsigned type: [N67] | ||||||||||||||||||||||||
| All conversions between signed and unsigned | X | Comments: | Will not be handled correct if the inputs | |||||||||||||||||||||
| types handle msb==1 as intended: [N78] | are large enough. This is documented in the FDD. | |||||||||||||||||||||||
| No possibility of dereferencing a null | X | Comments: | No explict check. Time execution | |||||||||||||||||||||
| pointer: [N70] | savings. Relies on user to ensure proper values are used. | |||||||||||||||||||||||
| Global outputs (RTE and Non-RTE) Initialized: | X | Comments: N/A | ||||||||||||||||||||||
| [N24] | ||||||||||||||||||||||||
| Module outputs are limited to the legal range | X | Comments: N/A | ||||||||||||||||||||||
| defined in the FDD Data dictionary: [N53] | ||||||||||||||||||||||||
| All code is mapped with FDD (all FDD | X | Comments: | No FDD references to be used. | |||||||||||||||||||||
| subfunctions and/or model blocks identified | ||||||||||||||||||||||||
| with code comments; all code corresponds to | ||||||||||||||||||||||||
| some FDD subfunction and/or model block): [N40] | ||||||||||||||||||||||||
| Struct types used for NvM have | X | Comments: N/A | ||||||||||||||||||||||
| elements declared in decreasing order by size | ||||||||||||||||||||||||
| and are not nested or used in arrays: [N84], [N85] | ||||||||||||||||||||||||
| No violations of other coding standard rules | X | Comments: | Noted in this document for all that | |||||||||||||||||||||
| identified during review | exist. | |||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Change Owner: | Kevin Smith | Review Date : | 02/26/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Selva | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | ||||||||||||||||||||||||
Sheet 3: QAC
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (QAC Review) | ||||||||||||||||||||||||
| Module Name: | Source File Revision: | 1 | Module | 1 | of | 1 | ||||||||||||||||||
| Compliance Guidelines Version: | N/A | |||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | QAC version is correct and did not change (List version) | X | Comments: | TL100A_QACSuprt_1.0.0 | ||||||||||||||||||||
| Contract Folder's header files are appropriate | X | Comments: | ||||||||||||||||||||||
| Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Guidelines | X | Comments: | MemMap include deviation documented | ||||||||||||||||||||
| Cyclomatic complexity and Static path count ok per | X | Comments: | ||||||||||||||||||||||
| Design and Coding Standards rule [N47] | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Change Owner: | Kevin Smith | Review Date : | 02/26/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Selva | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | ||||||||||||||||||||||||
Sheet 4: Integration Manual
12.1 - NxtrMath Integration Manual
Integration Manual
For
NxtrMath
VERSION: 1
DATE: 02/18/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 | Lucas Wendling | 1 | 02/18/15 |
Table of Contents
3.2 Global Functions(Non RTE) to be provided to Integration Project 6
4 Configuration REQUIREMeNTS 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
Abbrevations And Acronyms
| Abbreviation | Description |
References
This section lists the title & version of all the documents that are referred for development of this document
| Sr. No. | Title | 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
All functions in this component are provided to the integration project, but are only used on an as-needed basis.
Configuration REQUIREMeNTS
Build Time Config
| Modules | Notes | |
| None |
Configuration Files to be provided by Integration Project
<Configuration file that will generated from this components that will require Da Vinci Config generation or manual generation. Describe each parameter >
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
N/A
Required Global Data Outputs
N/A
Specific Include Path present
Yes
Runnable Scheduling
This section specifies the required runnable scheduling.
| Init | Scheduling Requirements | Trigger |
| None | None | RTE/ISR(<time>ms) |
| Runnable | Scheduling Requirements | Trigger |
| None | None | RTE/ISR(<time>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 |
| <Memmap usuage info> |
Table 1: ARM Cortex R4 Memory Usage
Non RTE NvM Blocks
| Block Name |
| <NVM block used Non RTE functions > |
Note : Size of the NVM block if configured in developer
RTE NvM Blocks
| Block Name |
| <NVM block used in RTE functions > |
Note : Size of the NVM block if configured in developer
Compiler Settings
Preprocessor MACRO
None
Optimization Settings
None
Appendix
<This section is for appendix>
12.2 - NxtrMath Review
Overview
Summary SheetSource Code
QAC
Integration Manual
Sheet 1: Summary Sheet
Sheet 2: Source Code
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (Source Code Review) | ||||||||||||||||||||||||
| Source File Name: | Source File Revision: | |||||||||||||||||||||||
| Module Design Document Name: | MDD Revision: | |||||||||||||||||||||||
| Data Dictionary Revision: | FDD/SER/CMS | |||||||||||||||||||||||
| and Revision: | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | Software Naming Convention V1.2 followed: | |||||||||||||||||||||||
| for variable names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for constant names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for function names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for other names (component, memory | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| mapping handles, typedefs, etc.) | ||||||||||||||||||||||||
| All buffered outputs written in every path, i.e. no | X | Comments: N/A | ||||||||||||||||||||||
| possibility of an uninitialized value being written | ||||||||||||||||||||||||
| Group-review Checklist (review board) | Synergy version matches change history | X | Comments: | |||||||||||||||||||||
| and Version Control version in file comment block | ||||||||||||||||||||||||
| Change log contains detailed description of changes | X | Comments: | ||||||||||||||||||||||
| and CR number | ||||||||||||||||||||||||
| Code accurately implements FDD (Document or Model) | X | Comments: | No FDD Currently Available | |||||||||||||||||||||
| No Compiler Errors or Warnings verified | X | Comments: | ||||||||||||||||||||||
| FDD test points exist as display variables: declared | X | Comments: N/A | ||||||||||||||||||||||
| static volatile, written once and never used, names | ||||||||||||||||||||||||
| match the FDD | ||||||||||||||||||||||||
| Software Design and Coding Standards V2.0 followed: | ||||||||||||||||||||||||
| Code comments are clear, correct, and adequate | X | 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 | X | Comments: | ||||||||||||||||||||||
| standards and contain correct information: [N41], [N42] | ||||||||||||||||||||||||
| Function comment blocks are per standards and | X | Comments: | ||||||||||||||||||||||
| contain correct information: [N43] | ||||||||||||||||||||||||
| Code formatting (indentation, placement of | X | Comments: | ||||||||||||||||||||||
| braces, etc.) is per standards: [N5], [N55], [N56], | ||||||||||||||||||||||||
| [N57], [N58], [N59] | ||||||||||||||||||||||||
| Embedded constants used per standards; no | X | Comments: | ||||||||||||||||||||||
| "magic numbers": [N12] | ||||||||||||||||||||||||
| All variables and constants defined at module | X | Comments: N/A for inline functions | ||||||||||||||||||||||
| level are included in appropriate MemMap | ||||||||||||||||||||||||
| section: [N25] and Naming Conventions | ||||||||||||||||||||||||
| All execution-order-dependent code can be | X | Comments: | ||||||||||||||||||||||
| recognized by the compiler: [N80] | ||||||||||||||||||||||||
| No possibility of a non-terminating loop: [N63] | X | Comments: | ||||||||||||||||||||||
| No possibility of divide by zero: [N65] | X | Comments: | ||||||||||||||||||||||
| All integer division and modulus operations | X | Comments: | ||||||||||||||||||||||
| handle negative numbers correctly: [N76] | ||||||||||||||||||||||||
| All typecasting and fixed point arithmetic, | X | Comments: | ||||||||||||||||||||||
| including all use of fixed point macros and | ||||||||||||||||||||||||
| timer functions, is correct and has no possibility | ||||||||||||||||||||||||
| of unintended overflow or underflow: [N66] | ||||||||||||||||||||||||
| No possibility of converting a negative floating | X | Comments: | ||||||||||||||||||||||
| point value to an unsigned type: [N67] | ||||||||||||||||||||||||
| All conversions between signed and unsigned | X | Comments: | ||||||||||||||||||||||
| types handle msb==1 as intended: [N78] | ||||||||||||||||||||||||
| No possibility of dereferencing a null | X | Comments: N/A | ||||||||||||||||||||||
| pointer: [N70] | ||||||||||||||||||||||||
| Global outputs (RTE and Non-RTE) Initialized: | X | Comments: N/A | ||||||||||||||||||||||
| [N24] | ||||||||||||||||||||||||
| Module outputs are limited to the legal range | X | Comments: N/A | ||||||||||||||||||||||
| defined in the FDD Data dictionary: [N53] | ||||||||||||||||||||||||
| All code is mapped with FDD (all FDD | X | Comments: No FDD Available | ||||||||||||||||||||||
| subfunctions and/or model blocks identified | ||||||||||||||||||||||||
| with code comments; all code corresponds to | ||||||||||||||||||||||||
| some FDD subfunction and/or model block): [N40] | ||||||||||||||||||||||||
| Struct types used for NvM have | X | Comments: N/A | ||||||||||||||||||||||
| elements declared in decreasing order by size | ||||||||||||||||||||||||
| and are not nested or used in arrays: [N84], [N85] | ||||||||||||||||||||||||
| No violations of other coding standard rules | X | Comments: | ||||||||||||||||||||||
| identified during review | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| DONE: Change names on functions to ensure that return type is captured in function name. i.e. FunName_rettype_<optional parametertype> | ||||||||||||||||||||||||
| DONE: Add usage notes to header for input range restrictions, paramaters being in radians, etc | ||||||||||||||||||||||||
| Follow up with lonnie on limiting or checking for input strategy… no direct answers needed for design but need to see if future discussions are needed | ||||||||||||||||||||||||
| DONE: Check spelling (positive misspelled) | ||||||||||||||||||||||||
| DONE: Re-review before synergy checkin for all version numbers | ||||||||||||||||||||||||
| Change Owner: | Lucas Wendling | Review Date : | 02/18/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Kathleen | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | Selva | Spandana | Jerry | |||||||||||||||||||||
| Temi | ||||||||||||||||||||||||
Sheet 3: QAC
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (QAC Review) | ||||||||||||||||||||||||
| Module Name: | Source File Revision: | 1 | Module | 1 | of | 1 | ||||||||||||||||||
| Compliance Guidelines Version: | Working EA4 version | |||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | QAC version is correct and did not change (List version) | X | Comments: | Using working EA4 version plus special analyzer file which was reviewed | ||||||||||||||||||||
| Contract Folder's header files are appropriate | X | Comments: | ||||||||||||||||||||||
| Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Guidelines | X | Comments: | Deviations added per reviewer agreement | ||||||||||||||||||||
| Cyclomatic complexity and Static path count ok per | X | Comments: | ||||||||||||||||||||||
| Design and Coding Standards rule [N47] | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Polyspace results analyzed as well | ||||||||||||||||||||||||
| Change Owner: | Lucas Wendling | Review Date : | 02/18/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Kathleen | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | Selva | Spandana | Jerry | |||||||||||||||||||||
| Temi | ||||||||||||||||||||||||
Sheet 4: Integration Manual
13.1 - NxtrTi Integration Manual
Integration Manual
For
NxtrTi
VERSION: 1
DATE: 02/16/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 | L. Wendling | 1 | 02/16/2015 |
Table of Contents
3.2 Global Functions(Non RTE) to be provided to Integration Project 6
4 Configuration REQUIREMeNTS 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
Abbrevations And Acronyms
| Abbreviation | Description |
References
This section lists the title & version of all the documents that are referred for development of this document
| Sr. No. | Title | 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
See section 6. Please note the server runnables listed can be used as needed in the integration project and can be called via the RTE or outside of the RTE as required.
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
N/A
Required Global Data Outputs
N/A
Specific Include Path present
Yes
Runnable Scheduling
This section specifies the required runnable scheduling.
| Init | Scheduling Requirements | Trigger |
| NxtrTiInit0 | Can be called prior to O/S start if timer usage is needed before the RTE initialization tasks execute | Initialization |
| NxtrTiInit1 | RTE Init Task |
| Runnable | Scheduling Requirements | Trigger |
| NxtrTiPer1 | None | RTE 2ms Task |
| GetRefTmr100MicroSec32bit_Oper | Server Runnable | Client Call |
| GetRefTmr1MicroSec32bit_Oper | Server Runnable | Client Call |
| GetTiSpan100MicroSec32bit_Oper | Server Runnable | Client Call |
| GetTiSpan1MicroSec32bit_Oper | Server Runnable | Client Call |
.
Memory Map REQUIREMENTS
Mapping
| Memory Section | Contents | Notes |
| CDD_NxtrTi_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
Non RTE NvM Blocks
| Block Name |
| <NVM block used Non RTE functions > |
Note : Size of the NVM block if configured in developer
RTE NvM Blocks
| Block Name |
| <NVM block used in RTE functions > |
Note : Size of the NVM block if configured in developer
Compiler Settings
Preprocessor MACRO
None
Optimization Settings
None
Appendix
<This section is for appendix>
13.2 - NxtrTi Review
Overview
Summary SheetDavinci Files
Source Code CDD_NxtrTi
QAC CDD_NxtrTi
Sheet 1: Summary Sheet
Sheet 2: Davinci Files
Sheet 3: Source Code CDD_NxtrTi
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (Source Code Review) | ||||||||||||||||||||||||
| Source File Name: | Source File Revision: | |||||||||||||||||||||||
| Module Design Document Name: | MDD Revision: | |||||||||||||||||||||||
| Data Dictionary Revision: | FDD/SER/CMS | |||||||||||||||||||||||
| and Revision: | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | Software Naming Convention V1.2 followed: | |||||||||||||||||||||||
| for variable names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for constant names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for function names | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| for other names (component, memory | X | Comments: Per working EA4 Naming Conventions | ||||||||||||||||||||||
| mapping handles, typedefs, etc.) | ||||||||||||||||||||||||
| All buffered outputs written in every path, i.e. no | X | Comments: N/A | ||||||||||||||||||||||
| possibility of an uninitialized value being written | ||||||||||||||||||||||||
| Group-review Checklist (review board) | Synergy version matches change history | X | Comments: | |||||||||||||||||||||
| and Version Control version in file comment block | ||||||||||||||||||||||||
| Change log contains detailed description of changes | X | Comments: | ||||||||||||||||||||||
| and CR number | ||||||||||||||||||||||||
| Code accurately implements FDD (Document or Model) | X | Comments: | No FDD Currently Available | |||||||||||||||||||||
| No Compiler Errors or Warnings verified | X | Comments: | Extra semicolon warning from register | |||||||||||||||||||||
| definition macros. Not fixing currently since this is Type 1b files. | ||||||||||||||||||||||||
| FDD test points exist as display variables: declared | X | Comments: N/A | ||||||||||||||||||||||
| static volatile, written once and never used, names | ||||||||||||||||||||||||
| match the FDD | ||||||||||||||||||||||||
| Software Design and Coding Standards V2.0 followed: | ||||||||||||||||||||||||
| Code comments are clear, correct, and adequate | X | 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 | X | Comments: | ||||||||||||||||||||||
| standards and contain correct information: [N41], [N42] | ||||||||||||||||||||||||
| Function comment blocks are per standards and | X | Comments: | ||||||||||||||||||||||
| contain correct information: [N43] | ||||||||||||||||||||||||
| Code formatting (indentation, placement of | X | Comments: | ||||||||||||||||||||||
| braces, etc.) is per standards: [N5], [N55], [N56], | ||||||||||||||||||||||||
| [N57], [N58], [N59] | ||||||||||||||||||||||||
| Embedded constants used per standards; no | X | Comments: | ||||||||||||||||||||||
| "magic numbers": [N12] | ||||||||||||||||||||||||
| All variables and constants defined at module | X | Comments: N/A | ||||||||||||||||||||||
| level are included in appropriate MemMap | ||||||||||||||||||||||||
| section: [N25] and Naming Conventions | ||||||||||||||||||||||||
| All execution-order-dependent code can be | X | Comments: N/A | ||||||||||||||||||||||
| recognized by the compiler: [N80] | ||||||||||||||||||||||||
| No possibility of a non-terminating loop: [N63] | X | Comments: N/A | ||||||||||||||||||||||
| No possibility of divide by zero: [N65] | X | Comments: | ||||||||||||||||||||||
| All integer division and modulus operations | X | Comments: N/A | ||||||||||||||||||||||
| handle negative numbers correctly: [N76] | ||||||||||||||||||||||||
| All typecasting and fixed point arithmetic, | X | Comments: | ||||||||||||||||||||||
| including all use of fixed point macros and | ||||||||||||||||||||||||
| timer functions, is correct and has no possibility | ||||||||||||||||||||||||
| of unintended overflow or underflow: [N66] | ||||||||||||||||||||||||
| No possibility of converting a negative floating | X | Comments: | ||||||||||||||||||||||
| point value to an unsigned type: [N67] | ||||||||||||||||||||||||
| All conversions between signed and unsigned | X | Comments: | ||||||||||||||||||||||
| types handle msb==1 as intended: [N78] | ||||||||||||||||||||||||
| No possibility of dereferencing a null | X | Comments: | ||||||||||||||||||||||
| pointer: [N70] | ||||||||||||||||||||||||
| Global outputs (RTE and Non-RTE) Initialized: | X | Comments: N/A | ||||||||||||||||||||||
| [N24] | ||||||||||||||||||||||||
| Module outputs are limited to the legal range | X | Comments: N/A | ||||||||||||||||||||||
| defined in the FDD Data dictionary: [N53] | ||||||||||||||||||||||||
| All code is mapped with FDD (all FDD | X | Comments: No FDD avaialble yet | ||||||||||||||||||||||
| subfunctions and/or model blocks identified | ||||||||||||||||||||||||
| with code comments; all code corresponds to | ||||||||||||||||||||||||
| some FDD subfunction and/or model block): [N40] | ||||||||||||||||||||||||
| Struct types used for NvM have | X | Comments: N/A | ||||||||||||||||||||||
| elements declared in decreasing order by size | ||||||||||||||||||||||||
| and are not nested or used in arrays: [N84], [N85] | ||||||||||||||||||||||||
| No violations of other coding standard rules | X | Comments: | ||||||||||||||||||||||
| identified during review | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| TODO: requirements traceability when requirements are available | ||||||||||||||||||||||||
| Change Owner: | Kathleen Creager | Review Date : | 04/13/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Lucas Wendling | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | ||||||||||||||||||||||||
Sheet 4: QAC CDD_NxtrTi
| Rev 6.0 | 28-Oct-14 | |||||||||||||||||||||||
| Peer Review Meeting Log (QAC Review) | ||||||||||||||||||||||||
| Module Name: | Source File Revision: | 2 | Module | 1 | of | 2 | ||||||||||||||||||
| Compliance Guidelines Version: | EA4 Working Guidelines | |||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Yes | No | Rationale is required for all answers of No | ||||||||||||||||||||||
| Pre-review checklist for change owners | QAC version is correct and did not change (List version) | X | Comments: | |||||||||||||||||||||
| TL100A_QACSuprt_1.1.0 | ||||||||||||||||||||||||
| Contract Folder's header files are appropriate | X | Comments: | ||||||||||||||||||||||
| Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Guidelines | X | Comments: | Working EA4 Version | ||||||||||||||||||||
| Cyclomatic complexity and Static path count ok per | X | Comments: | ||||||||||||||||||||||
| Design and Coding Standards rule [N47] | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Polyspace - 21.1 in codeprover, 8.10 in bugfinder | ||||||||||||||||||||||||
| QAC only gives warning for 8.8; Polyspace only gives warning for 8.10 and 21.1 | ||||||||||||||||||||||||
| Change Owner: | Kathleen Creager | Review Date : | 04/13/15 | |||||||||||||||||||||
| Lead Peer Reviewer: | Lucas Wendling | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | ||||||||||||||||||||||||