TMS570 MCU Diag
TMS570 MCU Diag
Component Documentation
1 - Cd_uDiag_Integration_Manual
1 Dependencies 2
1.1 SWCs 2
1.2 Functions to be provided to Integration Project 2
2 Configuration 3
2.1 Build Time Config 3
2.2 Configuration Files to be provided by Integration Project 3
2.2.1 Da Vinci Parameter Configuration Changes 4
2.2.2 DaVinci Interrupt Configuration Changes 5
2.2.3 Manual Configuration Changes 5
3 Integration 5
3.1 Required Global Data Inputs 5
3.2 Optional Global Data Inputs 5
3.3 Specific Include Path present 5
4 Runnable Scheduling 5
5 Memory Mapping 7
5.1 Mapping 7
5.2 Usage 7
5.3 NvM Blocks 7
6 Compiler Settings 7
6.1 Preprocessor MACRO 7
6.2 Optimization Settings 7
7 Revision Control Log 8
Dependencies
NOTE – the TMS570_uDiag component includes both uDiag and FlsTst functionality. For complete integration information on the TMS570_uDiag component, also see the FlsTst integration manual (in the TMS570_uDiag\doc folder).
SWCs
| Module | Required Feature |
|---|
| TMS570_Startup | _coreGetFPSCR_() _coreGetSecondaryAuxiliaryControlRegister_() _coreSetSecondaryAuxiliaryControlRegister_() Reset Causes: FPUDZCEXCP, FPUOFCEXCP, FPUIOCEXCP, FPUUNKNOWNEXCP _fiqhandler** |
| Basic System Services | EnableVFPInterrupt()* EnableESMLInterrupt()*** |
| |
NOTES:
*When uDiagEnableFPUDiag is set to STD_OFF, the floating point exception diagnostic is disabled and EnableVFPInterrupt() is optional.
**_fiqhandler needed only if configuring Mcu_FpuIrq as an interrupt (see section 2.2.2).
*** EnableESMLInterrupt() is now called from a function in the TMS570_uDiag component, as of component version FDD32B_TMS570_uDiag_000.23. When using component version FDD32B_TMS570_uDiag_000.23 or later, any other call(s) to the EnableESMLInterrupt() function, e.g. in EcuStartup, must be removed. This fixes anomaly 6133.
Functions to be provided to Integration Project
< Global function (except the ones that are defined in RTE modules) that is defined in this component but used by other function>
FUNC(void, CD_UDIAG_APPL_CODE) uDiagFPU_Init1(void);
FUNC(void, CD_UDIAG_APPL_CODE) uDiagFPU_Init2(void);
UDIAG_COMPILER_ISR void Mcu_FpuIrq(void);
FUNC(void, CD_UDIAG_APPL_CODE) uDiagCCRM_Init(void);
FUNC(void, CD_UDIAG_APPL_CODE) uDiagClockMonitor_Init(void);
FUNC(void, CD_UDIAG_APPL_CODE) uDiagECC_Init(void);
FUNC(void, CD_UDIAG_APPL_CODE) uDiagESM_Init(void);
FUNC(void, CD_UDIAG_APPL_CODE) uDiagIOMM_Init(void);
FUNC(void, CD_UDIAG_APPL_CODE) uDiagParity_Init(void);
FUNC(void, CD_UDIAG_APPL_CODE) uDiagStaticRegs_Init(void);
FUNC(void, CD_UDIAG_APPL_CODE) uDiagVIM_Init(void);
Configuration
Build Time Config
Configuration Files to be provided by Integration Project
uDiag_Cfg.c generated from uDiag_Cfg.c.tt
uDiag_Cfg.h generated from uDiag_Cfg.h.tt
Da Vinci Parameter Configuration Changes
| Parameter | Notes | SWC |
|---|
| uDiagGeneral\uDiagEnableFPUDiag | When set to STD_ON,the floating point exception diagnostic is enabled. When set to STD_OFF, the diagnostic is disabled, the EnableVFPInterrupt() function (see section 1.1) is optional, interrupt configuration of Mcu_FpuIrq (see section 2.2.2) is optional, and the calls to uDiagFPU_Init1() and uDiagFPU_Init2() (see section 4) are optional. | TMS570_uDiag |
| OsOSFIQHandler\NONO_AUTO\OsOSFIQHandler | Must be set to “_fiqhandler” when Mcu_FpuIrq is configured as an interrupt. (See section 2.2.2). | Os |
| uDiagGeneral\uDiagGladiatorCompatible | Must be set to STD_ON for programs where code compatibility is required between Gladiator and Champion parts.* Set to STD_OFF for programs where only Champion parts are used. | TMS570_uDiag |
| uDiagGeneral\uDiagVIMPerTrusted | Set to STD_ON when uDiagVIM_Per() is called from a trusted task. Set to STD_OFF when uDiagVIM_Per() is called from a non-trusted task. NOTE that when this parameter is set to STD_OFF, the void function TWrapS_uDiagVIM_RednRpdShtdn(void) must be added as a trusted function. | TMS570_uDiag |
| uDiagGeneral\uDiagECCPerTrusted | Set to STD_ON when uDiagECC_Per() is called from a trusted task. Set to STD_OFF when uDiagECC_Per() is called from a non-trusted task. NOTE that when this parameter is set to STD_OFF, the void function TWrapS_uDiagECC_RednRpdShtdn(void) must be added as a trusted function. | TMS570_uDiag |
| | |
*The uDiagGladiatorCompatible parameter selects ESM Group 1 Channel 7 (as used on Gladiator) vs Group 1 Channel 34 (as used on Champion) for NHET2 Parity Error. On programs where code compatibility is required, the Gladiator ESM configuration must be used, because the Champion configuration enables an interrupt that is Reserved for Gladiator. NOTE that on Champion parts running code configured as Gladiator-compatible, an NHET2 RAM Parity Error will trigger only a Critical Registers Verification Fault , with no NHET2 RAM Fault diagnostic.
DaVinci Interrupt Configuration Changes
| ISR Name | VIM # | Priority Dependency | Notes |
|---|
| Mcu_FpuIrq | 47 | higher priority than any other FIQ that uses floating point | Must be an FIQ and Category 1 when configured, and if FIRQPR0 is included in the runtime register check, its value needs to be changed in the RuntimeRegCheck configuration. When uDiagEnableFPUDiag is set to STD_OFF, the floating point exception diagnostic is disabled and the interrupt configuration of Mcu_FpuIrq is optional. |
| Isr_ESMH | 0 | Highest priority FIQ | Must be FIQ and Category 1 |
| Isr_ESML | 20 | | Must be IRQ and Category 2 |
| | | |
| | | |
Manual Configuration Changes
Integration
<Mention any global variable that this component requires for other components>
ResetCause_Cnt_Enum
<Mention any global variable that this component requires for other components>
Specific Include Path present
<Yes>
Runnable Scheduling
This section specifies the required runnable scheduling.
| Init | Scheduling Requirements | Trigger |
|---|
| uDiagCCRM_Init | Before the OS is started | ECU Startup |
| uDiagClockMonitor_Init | Before the OS is started | ECU Startup |
| uDiagECC_Init | Before the OS is started | ECU Startup |
| uDiagESM_Init | Before the OS is started | ECU Startup |
| uDiagIOMM_Init | Before the OS is started | ECU Startup |
| uDiagParity_Init | Before the OS is started | ECU Startup |
| uDiagStaticRegs_Init | Before the OS is started | ECU Startup |
| uDiagVIM_Init | Before the OS is started | ECU Startup |
| uDiagFPU_Init1* | Before the OS is started | ECU Startup |
| uDiagFPU_Init2* | After the OS is started, before any code that uses floating point | ECU Startup |
*NOTE: When uDiagEnableFPUDiag is set to STD_OFF, the floating point exception diagnostic is disabled and the calls to uDiagFPU_Init1() and uDiagFPU_Init2() are optional.
| Runnable | Scheduling Requirements | Trigger |
|---|
| <Runnable name> | None | RTE/ISR(<time>ms) |
Memory Mapping
Mapping
| Memory Section | Contents | Notes |
|---|
| UDIAG_START_SEC_VAR_SAVED_UNSPECIFIED | FPUExceptionAddr_Cnt_D_u32 | do not clear on reset |
| UDIAG_START_SEC_VAR_CLEARED_UNSPECIFIED | | |
| UDIAG_START_SEC_VAR_CLEARED_BOOLEAN | | |
| UDIAG_START_SEC_VAR_CLEARED_16 | | |
| UDIAG_START_SEC_VAR_CLEARED_32 | | |
| WDGRESETHANDLER_START_SEC_VAR_POWER_ON_CLEARED_8 | | |
* Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.
Usage
Table 1: ARM Cortex R4 Memory Usage
| Feature | RAM | ROM |
|---|
| <Memmap usuage info> | | |
NvM Blocks
| Block Name |
|---|
| <NvM Block Info> |
Note : Size of the NVM block if configured in developer
Compiler Settings
Preprocessor MACRO
<Define all the preprocessor Macros needed and conditions when needed>.
Optimization Settings
Revision Control Log
| Rev # | Change Description | Date | Author |
| 1 | Initial version – includes information for Cd_uDiagFPU and Cd_uDiagUtility only | 6-Jun-2013 | Kathleen Creager |
| 2 | Added uDiagGeneral\uDiagEnableFPUDiag to configuration parameters, and related notes, for enabling/disabling floating point exception diagnostic. Added “Category 1” and mention of Runtime Register Check to notes on configuring Mcu_FpuIrq. Added OsOSFIQHandler configuration parameter. Clarified scheduling requirements on uDiagFPU_Init2(). | 26-Jun-13 | KMC |
| 3 | Added information on parameters uDiagGladiatorCompatible and uDiagVIMPerTrusted,FlsTstBlockSize, interrupt routines, and optimization settings as needed for changes made to fix anomalies 5403, 5801, 5491, 5809, and 5810. NOTE that this integration manual is not complete; it includes only information related to changes made to the component beginning in June 2013.. | 16-Oct-13 | KMC |
| 4 | Updated for change to call init functions from EcuStartup instead of as RTE init functions, and removed unneeded instructions about inlining compiler directive, both changes per CR11158. Added dependency and note regarding EnableESMLInterrupt() per CR 11157. Other misc cleanup. | 06-Jan-14 | KMC |
2 - Cd_uDiagFPU_MDD
High-Level Description
Cd_uDiagFPU provides diagnostic data on floating point exceptions. Based on “Unreleased draft of EA3.x FDD 32.5 uC Diagnostics Execution (0x02A-0x031) v002.docx” as saved on May 7, 2013 and “Unreleased Draft of EA3.x FDD 32.Appendices v002.docx” as saved on May 6, 2013.
On initialization, it sets up the Secondary Auxiliary Control Register to generate a floating point interrupt (VIM47) on the occurrence of any of these floating point exception flags: IOC (invalid operation), OFC (overflow), or DZC (divide by zero), and enables the floating point interrupt. When the floating point interrupt occurs, the module’s ISR saves program address information (to indicate where the exception occurred) and a reset reason indicating the type of exception, and causes a reset.
Cd_uDiagFPU functionality is enabled/disabled by D_ENABLEFPUDIAG_CNT_LGC. See Integration Manual for the configuration parameter that controls this #define.
Diagram – Function Data Sharing
No Shared Data
Variable Data Dictionary
For details on module input / output variable, refer to the Data Dictionary for the application. Input / output variable names are listed here for reference.
(Note: Full variable names required in table.)
(Note: All global variables including End Of Line data used should be shown here)
| Module Inputs | Module Outputs |
|---|
| ResetCause_Cnt_Enum | ResetCause_Cnt_Enum |
| |
Module Internal Variables
This section identifies the name, range and resolutions for module specific data created by this module. If there are no range restrictions on the variable, the term “FULL” is placed into the table for legal range.
| Variable Name | Resolution | Legal Range (min) | Legal Range (max) | Software Segment |
|---|
| FPUExceptionAddr_Cnt_D_u32 | NA | FULL | FULL | See Integration Manual |
| | | | |
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) |
|---|
| <None> | | | | |
| | | | |
Constant Data Dictionary
Calibration Constants
This section lists the calibrations used by the module. For details on calibration constants, refer to the Data Dictionary for the application.
Program(fixed) Constants
Embedded Constants
All embedded constants whose values are provided in Eng units will be evaluated to the equivalent counts by using the FPM_InitFixedPoint_m() macro within the #define statement.
Local
| Constant Name | Resolution | Units | Value |
|---|
| D_FPSCRBITIOC_CNT_U32 | N/A | N/A | 0x00000001 |
| D_FPSCRBITDZC_CNT_U32 | N/A | N/A | 0x00000002 |
| D_FPSCRBITOFC_CNT_U32 | N/A | N/A | 0x00000004 |
| D_VFPEXCEPTIONOUTPUTEN_CNT_U32 | N/A | N/A | 0x00001600 |
Global
This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application.
| Constant Name |
|---|
| FPUDZCEXCP |
| FPUOFCEXCP |
| FPUIOCEXCP |
| FPUUNKNOWNEXCP |
| D_ENABLEFPUDIAG_CNT_LGC |
Module specific Lookup Tables Constants
(This is for lookup tables (arrays) with fixed values, same name as other tables)
| Constant Name | Resolution | Value | Software Segment |
|---|
| <None> | | | |
Functions/Macros used by the Sub-Modules
Library Functions / Macros
The library and functions / Macros that are called by the various sub modules are identified below,
RednRpdShtdn()
Data Hiding Functions
_coreGetSecondaryAuxiliaryControlRegister_()
_coreSetSecondaryAuxiliaryControlRegister_()
_coreGetFPSCR_()
EnableVFPInterrupt()
_uDiagGetLinkRegForFiqIsr_()
Global Functions/Macros Defined by this Module
Global Function #1
| Function Name | uDiagFPU_Init1 | Type | Dir. | Min | Max | UTP Tol. |
| Arguments Passed | None | | | | | |
| Return Value | N/A | | | | | |
Design Rationale
When the reset cause was a floating point exception, need to ensure that shutdown can be reached without another floating point exception occurring . Therefore the floating point exceptions should only be enabled when the reset cause was NOT a floating point exception.
When built with D_ENABLEFPUDIAG_CNT_LGC == STD_ON, the function operates as shown in 5.3.1.2. When built with D_ENABLEFPUDIAG_CNT_LGC == STD_OFF, the function returns without doing anything.
Description
Global Function #2
| Function Name | uDiagFPU_Init2 | Type | Dir. | Min | Max | UTP Tol. |
| Arguments Passed | None | | | | | |
| Return Value | N/A | | | | | |
Design Rationale
When the reset cause was a floating point exception, need to ensure that shutdown can be reached without another floating point exception occurring . Therefore the floating point interrupt should only be enabled when the reset cause was NOT a floating point exception.
When built with D_ENABLEFPUDIAG_CNT_LGC == STD_ON, the function operates as shown in 5.3.2.2. When built with D_ENABLEFPUDIAG_CNT_LGC == STD_OFF, the function returns without doing anything.
Description
Local Functions/Macros Used by this MDD only
None
Software Module Implementation
Runtime Environment (RTE) Initial Values
This section lists the initial values of data written by this module but controlled by the RTE. After RTE initialization, the data in this table will contain these values.
Initialization Functions
None
Periodic Functions
None
Fault Recovery Functions
None
Shutdown Functions
None
Interrupt Functions
Isr: Mcu_FpuIrq()
Design Rationale
The floating point interrupt is set up as an FIQ so that it is the highest priority interrupt in the system (see section 9.2).
When a floating point interrupt occurs, need to ensure that shutdown is reached even if floating point processing is not operational. Therefore, this ISR calls the Redundant Rapid Shutdown function with a reset reason indicating which type of floating point exception occurred. The shutdown function resets the processor, so control does not return from this floating point interrupt ISR. After the reset, the reset handler sets a DTC shutdown fault with parameter bit(s) set to indicate the type of floating point exception.
Only three of six possible floating point exceptions are enabled. Also, if this interrupt is not the highest priority interrupt in the system, it is possible that the Floating Point Status and Control Register will no longer indicate an exception on entry to this ISR (see section 9.2). Therefore, in addition to reset reasons for the three expected floating point exception types, an “Unknown FP Exception” type will be indicated if none of the three expected types is seen in the status register.
When built with D_ENABLEFPUDIAG_CNT_LGC == STD_OFF, this function will never be invoked because the interrupt will not be enabled in the uDiagFPU_Init2() function.
Processing
Serial Communication Functions
None
Execution Requirements
See Integration Manual.
Memory Map Definition Requirements
Sub Modules (Functions)
This table identifies the software segments for functions identified in this module.
| Name of Sub Module | Software Segment |
|---|
| uDiagFPU_Init1 | N/A |
| uDiagFPU_Init2 | N/A |
| Mcu_FpuIrq | N/A |
Local Functions
This table identifies the software segments for local functions identified in this module.
| Name of Local Function | Software Segment |
|---|
| None | |
| |
Known Issues / Limitations With Design
Saved program address where exception occurred is actually the contents of the link register; it will usually give the address of the instruction at or shortly after where the exception occurred. However, under some circumstances the address may not indicate where the exception occurred.
If a floating point exception occurs in an ISR that has higher priority than the floating point exception ISR, entry to the floating point ISR will not occur until after the return from the ISR where the actual exception occurred. Because the processor saves/restores the Link Register and the Floating Point Status and Control register to/from the stack on interrupt, these registers will no longer contain the relevant information about the floating point exception after the return from the higher priority ISR, so the information will not be available to the floating point exception ISR. In this case, the reset reason will indicate Unknown Floating Point Exception, and the saved program address information will not be related to the occurrence of the exception.
NOTE that D_ENABLEFPUDIAG_CNT_LGC is controlled by a configuration parameter and will be defined in the private section of uDiag_Cfg.h. For the D_ENABLEFPUDIAG_CNT_LGC symbol to be properly defined on compilation of uDiagFPU.c, the uDiagFPU.c file must include these lines:
#define UDIAG_C /* to include module private section of header */
#include "uDiag.h"
and uDiag.h must include uDiag_Cfg.h.
If the D_ENABLEFPUDIAG_CNT_LGC symbol is not defined at compilation of this code, e.g. if the above includes are not properly set up, the floating point exception handling WILL be present and functional regardless of the configuration parameter setting..
Revision Control Log
| Rev # | Change Description | Date | Author Initials |
| 1.0 | Initial Revision | 6/6/2013 | KMC |
| 2.0 | Added D_ENABLEFPUDIAG_CNT_LGC to enable/disable floating point exception diagnostic functionality. | 6/26/13 | KMC |
3 - Cd_uDiagUtility_MDD
High-Level Description
Cd_uDiagUtility provides utility assembly language functions needed by the Cd_uDiag component.
Diagram – Function Data Sharing
No Shared Data
Variable Data Dictionary
For details on module input / output variable, refer to the Data Dictionary for the application. Input / output variable names are listed here for reference.
(Note: Full variable names required in table.)
(Note: All global variables including End Of Line data used should be shown here)
| Module Inputs | Module Outputs |
|---|
| <None> | <None> |
| |
Module Internal Variables
This section identifies the name, range and resolutions for module specific data created by this module. If there are no range restrictions on the variable, the term “FULL” is placed into the table for legal range.
| Variable Name | Resolution | Legal Range (min) | Legal Range (max) | Software Segment |
|---|
| <None> | | | | |
| | | | |
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) |
|---|
| <None> | | | | |
| | | | |
Constant Data Dictionary
Calibration Constants
This section lists the calibrations used by the module. For details on calibration constants, refer to the Data Dictionary for the application.
Program(fixed) Constants
Embedded Constants
All embedded constants whose values are provided in Eng units will be evaluated to the equivalent counts by using the FPM_InitFixedPoint_m() macro within the #define statement.
Local
| Constant Name | Resolution | Units | Value |
|---|
| <None> | | | |
Global
This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application.
Module specific Lookup Tables Constants
(This is for lookup tables (arrays) with fixed values, same name as other tables)
| Constant Name | Resolution | Value | Software Segment |
|---|
| <None> | | | |
Functions/Macros used by the Sub-Modules
Library Functions / Macros
The library and functions / Macros that are called by the various sub modules are identified below,
<None>
Data Hiding Functions
<None>
Global Functions/Macros Defined by this Module
Global Function #1
| Function Name | _uDiagGetLinkRegForFiqIsr_() | Type | Dir. | Min | Max | UTP Tol. |
| Arguments Passed | None | | | | | |
| Return Value | Link Register as saved in top stack frame when executing an FIQ ISR | uint32 | | FULL | FULL | |
Description
The saved link register is at offset 0x5C from the top of the stack. Load saved link register value to register R0 and return.
ldr r0, [sp, #0x5C]
bx lr
Local Functions/Macros Used by this MDD only
None
Software Module Implementation
Runtime Environment (RTE) Initial Values
This section lists the initial values of data written by this module but controlled by the RTE. After RTE initialization, the data in this table will contain these values.
Initialization Functions
None
Periodic Functions
None
Fault Recovery Functions
None
Shutdown Functions
None
Interrupt Functions
None
Serial Communication Functions
None
Execution Requirements
Execution Sequence of the Module
(Describe in words relevant details about the execution sequence of the different sub modules.)
Execution Rates for sub-modules called by the Scheduler
This table serves as reference for the Scheduler design
| Function Name | Calling Frequency | System State(s) in which the function is called |
|---|
| <None> | | |
Execution Requirements for Serial Communication Functions
| Function Name | Sub-Module called by (Serial Comm Function Name) |
|---|
| <None> | |
Memory Map Definition Requirements
Sub Modules (Functions)
This table identifies the software segments for functions identified in this module.
| Name of Sub Module | Software Segment |
|---|
| _uDiagGetLinkRegForFiqIsr_ | N/A |
Local Functions
This table identifies the software segments for local functions identified in this module.
| Name of Local Function | Software Segment |
|---|
| None | |
| |
Known Issues / Limitations With Design
None
Revision Control Log
| Item # | Rev # | Change Description | Date | Author Initials |
| 1 | 1.0 | Initial Revision | 6/6/2013 | KMC |
4 - Data Dictionary
Overview
Change Log
Variable Dictionary
Calibration Dictionary
Template
Help
Sheet 1: Change Log
| uDiag - Rev 3 | <- Global Program / Module Name |
|
|
|
| Revision | Author | Date | Change Description |
|
| Data Dictionary Type: | Component |
| 1.0 | LWW | 27-Jul-12 | Initial Version |
|
|
|
|
| 3 | KMC | 6-Jun-13 | added FPUExceptionAddr_Cnt_D_u32, deleted Global Constants tab |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 2: Variable Dictionary
| uDiag - Rev 3 |
|
| I | O | M | D | N |
| Variable Information |
|
| Y | N |
|
|
|
|
|
|
|
|
|
|
| Range |
|
|
|
|
|
|
|
|
|
|
|
|
| Software Variable Name | Standard Reference Name | FDD Reference | Description | [I]nput
[O]uput
[M]oduleInternal
[D]isplay
[N]onVolatileMemory
Usage | OEM | 1X, 1Y, 1Z, 1I, 1B
2X, 2Y, 2Z, 2I, 2B
etc
Graph Settings | Initalization Value | Min | Max | Resolution | Unit Test Tolerance (+/-) | Units | Type | Memory Segment |
|
|
|
|
|
|
|
| Variables |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| FPUExceptionAddr_Cnt_D_u32 |
|
| Program Address where exception occurred | D |
|
| N/A | FULL | FULL | N/A | N/A | Counts | uint32 | CD_UDIAG_VAR_NOINIT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 3: Calibration Dictionary
| uDiag - Rev 3 |
|
|
| N |
| Calibration Information | Achieved in Software Design |
|
|
|
| Y |
|
|
|
|
|
|
|
| Range |
|
|
|
|
|
| P |
| Software Calibration Name | Standard Reference Name | FDD Reference | Description | Tuning Set | OEM | 1X, 1Y, 1Z, 1I, 1B
2X, 2Y, 2Z, 2I, 2B
etc
Graph Settings | Default Value | Min | Max | Units | Type | Memory Segment |
|
|
|
|
| Calibrations |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| k_FlashECCDiag_Cnt_str |
| FDD32B uCDiagnostics |
| N |
|
| {100, 5, 1} | N/A | N/A | N/A | DiagSettings_Str |
|
|
|
|
|
| k_FlashECCDiag_Cnt_str.PStep |
| FDD32B uCDiagnostics |
| N |
|
| 5 | FULL | FULL | Counts | uint16 |
|
|
|
|
|
| k_FlashECCDiag_Cnt_str.NStep |
| FDD32B uCDiagnostics |
| N |
|
| 1 | FULL | FULL | Counts | uint16 |
|
|
|
|
|
| k_FlashECCDiag_Cnt_str.Threshold |
| FDD32B uCDiagnostics |
| N |
|
| 100 | FULL | FULL | Counts | uint16 |
|
|
|
|
|
| k_RAMECCDiag_Cnt_str |
| FDD32B uCDiagnostics |
| N |
|
| {100, 5, 1} | N/A | N/A | N/A | DiagSettings_Str |
|
|
|
|
|
| k_RAMECCDiag_Cnt_str.PStep |
| FDD32B uCDiagnostics |
| N |
|
| 5 | FULL | FULL | Counts | uint16 |
|
|
|
|
|
| k_RAMECCDiag_Cnt_str.NStep |
| FDD32B uCDiagnostics |
| N |
|
| 1 | FULL | FULL | Counts | uint16 |
|
|
|
|
|
| k_RAMECCDiag_Cnt_str.Threshold |
| FDD32B uCDiagnostics |
| N |
|
| 100 | FULL | FULL | Counts | uint16 |
|
|
|
|
|
| k_MtrCtrlMinCount_Cnt_u16 |
| FDD32B uCDiagnostics |
| N |
|
| 10 | 1.00E+00 | 1.00E+03 | Counts | uint16 |
|
|
|
|
|
| k_MtrCtrlMaxCount_Cnt_u16 |
| FDD32B uCDiagnostics |
| N |
|
| 120 | 1.00E+00 | 1.00E+03 | Counts | uint16 |
|
|
|
|
|
| k_OneMsLoopMinCount_Cnt_u16 |
| FDD32B uCDiagnostics |
| N |
|
| 1 | 1.00E+00 | 1.00E+02 | Counts | uint16 |
|
|
|
|
|
| k_OneMsLoopMaxCount_Cnt_u16 |
| FDD32B uCDiagnostics |
| N |
|
| 11 | 1.00E+00 | 1.00E+02 | Counts | uint16 |
|
|
|
|
|
| k_VIMParErrThrsh_Cnt_u16 |
| FDD32B uCDiagnostics |
| N |
|
| 20 | 1.00E+00 | 1.00E+03 | Counts | uint16 |
|
|
|
|
|
Sheet 4: Template
| 2.2a | Data File: |
|
|
|
|
|
|
|
|
|
|
|
|
| Header: | extern <TYPE><TAB><NAME>; |
|
|
|
|
|
|
|
|
|
| Source: | #pragma DATA_SECTION(<ROOTNAME>, "<SEGMENT>");
<TYPE> <NAME>; |
|
|
|
|
|
|
|
|
|
| EOL Constants: |
|
|
|
|
|
|
|
|
|
|
|
|
| Header: | extern <TYPE><TAB><NAME>; |
|
|
|
|
|
|
|
|
|
| Source: | #pragma DATA_SECTION(<ROOTNAME>, "<SEGMENT>");
<TYPE> <NAME>; |
|
|
|
|
|
|
|
|
|
| Global (Embedded) Constants: |
|
|
|
|
|
|
|
|
|
|
|
|
| Header: | #define <NAME><COL40><VALUE> |
|
|
|
|
|
|
|
|
|
| A2L Name |
|
|
|
|
|
|
|
|
|
|
|
|
| Measurement: | rte_<SWC>_<NAME> |
|
|
|
|
|
|
|
|
|
| Calibration Constants: |
|
|
|
|
|
|
|
|
|
|
|
|
| Tuning ID: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Tuning: | N | Index Range: |
|
|
|
|
|
|
|
|
|
|
| Header: | extern CONST(<AUTOSAR_TYPE>, CAL_CONST) <NAME>; |
|
|
|
|
|
|
|
|
|
| Source: | #pragma DATA_SECTION(<ROOTNAME>, ".<SEGMENT>");
CONST(<AUTOSAR_TYPE>, CAL_CONST) <NAME> = <VALUE>; |
|
|
|
|
|
|
|
|
|
| eCal: | <NAME> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Tuning: | Y | Index Range: |
|
|
|
|
|
|
|
|
|
|
| Header: | extern CONST(<AUTOSAR_TYPE>, CAL_CONST) <NAME>; |
|
|
|
|
|
|
|
|
|
| Source: | #pragma DATA_SECTION(<ROOTNAME>, ".<SEGMENT>");
CONST(<AUTOSAR_TYPE>, CAL_CONST) <NAME> = <VALUE>; |
|
|
|
|
|
|
|
|
|
| eCal: | <NAME> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Tuning: | P | Index Range: |
|
|
|
|
|
|
|
|
|
|
| Header: | extern CONST(<AUTOSAR_TYPE>, CAL_CONST) <NAME>; |
|
|
|
|
|
|
|
|
|
| Source: | #pragma DATA_SECTION(<ROOTNAME>, ".<SEGMENT>");
CONST(<AUTOSAR_TYPE>, CAL_CONST) <NAME> = <VALUE>; |
|
|
|
|
|
|
|
|
|
| eCal: | <NAME> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 5: Help
| Short cut | Macro | Sescription |
| Ctrl-q | ClearDataDictFilter | Will clear all autofilters on the Global Data Dictionary |
|
|
|
| DFD_Create | Creates a Series of Data Flow Worksheet Pages from the information in the data dictionary. If Data Flow Worksheet pages already exist, they will be deleted first. |
| DFD_Delete | Will clear all Data Flow Diagram pages from the Data Dictionary. This will make the file smaller for archiving. |
| DFD_Print | Formate and prepares to print the Data Flow Worksheet pages. |
5 - FlsTst_Integration_Manual
Contents
1 Dependencies 1
1.1 SWCs 2
1.2 Functions to be provided to Integration Project 2
2 Configuration 2
2.1 Build Time Config 2
2.2 Configuration Files to be provided by Integration Project 2
2.2.1 Da Vinci Parameter Configuration Changes 3
2.2.2 DaVinci Interrupt Configuration Changes 3
2.2.3 Manual Configuration Changes 3
3 Integration 3
3.1 Required Global Data Inputs 3
3.2 Optional Global Data Inputs 4
3.3 Specific Include Path present 4
4 Runnable Scheduling 4
5 Memory Mapping 4
5.1 Mapping 4
5.2 Usage 4
5.3 NvM Blocks 5
6 Compiler Settings 5
6.1 Preprocessor MACRO 5
6.2 Optimization Settings 5
7 Revision Control Log 5
Dependencies
NOTE – the TMS570_uDiag component includes both uDiag and FlsTst functionality. For complete integration information on the TMS570_uDiag component, also see the Cd_uDiag integration manual (in the TMS570_uDiag\doc folder).
SWCs
| Module | Required Feature |
|---|
| NxtrLib | DtrmnElapsedTime_uS_u32() GetSystemTime_uS_u32() |
| TMS570 CRC peripheral | Exclusive access to the CRC peripheral registers. |
| TMS570 DMA peripheral | Exclusive access to the DMA peripheral registers. |
| TMS570 ESM peripheral | Exclusive access to the ESM configuration bits that control the DMA MPU interrupt enable, nError pin action, and Interrupt level mapping. |
| |
| DiagMgr (Nexteer DEM) | NxtrDiagMgr_ReportNTCStatus() API |
| uDiagESM | DMAMPUErr() Callback notification on DMA MPU violation |
| Basic System Services | EnableCRCInterrupt() |
Functions to be provided to Integration Project
< Global function (except the ones that are defined in RTE modules) that is defined in this component but used by other function>
void FlsTst_MainFunction( void );
void FlsTst_Init( const FlsTst_ConfigType* ConfigPtr );
void FlsTst_Suspend( void );
void FlsTst_Resume( void );
Configuration
Build Time Config
Configuration Files to be provided by Integration Project
FlsTst_Cfg.c generated by FlsTst_Cfg.c.tt
FlsTst_Cfg.h generated by FlsTst_Cfg.h.tt
NOTES: The FlsTst module parameter description file and generator templates are located in the “generate” folder. The generation scheme at this time relies on the ARTT generation framework developed by BMW. Following are the recommended steps to integrate the provided generation templates and parameter description with Davinci Configurator:
Copy the “Artt/artt” framework folder into the “Generators” directory (if not already present)
Execute the “Integrate.bat” script from the Tools directory of this component to perform the necessary integration steps:
The script creates the required directories in the integration project, “Generators/Artt/FlsTst” and “Generators/Components/_Schemes/FlsTst/bswmd”
The script then copies the required files from the CBD generate directory into the new directories.
If this is the first time integration, then perform the Davinci Configurator 3rd party component integration procedure.
Da Vinci Parameter Configuration Changes
| Parameter | Notes | SWC |
|---|
| | |
| FlsTstConfigSet | At least one block configuration set must be defined. See FlsTst technical reference for details. | FlsTst |
| FlsTstConfigurationOfOptApiServices | Configuration of optional API services. All optional services are disabled by default. | FlsTst |
| FlsTstDemEventParameterRefs | Configuration of NTC enumeration symbol name for diagnostic tests performed in this module. | FlsTst |
| FlsTstGeneral | General module configuration. See FlsTst technical reference for details. | FlsTst |
| FlsTst\Runtime\FlsTstBlockBgndConfigSet\App\FlsTstBlockSize | Number of bytes in flash test block – NOTE that this number has a max value of 8388600 in the current version of the uDiag component, and a max value of 524280 in version FDD32B_TMS570_uDiag_000.21 and previous. Numbers greater than the max value will not give an error indication but will cause the flash CRC check to not operate correctly. | FlsTst (contained in TMS570_uDiag component) |
DaVinci Interrupt Configuration Changes
| ISR Name | VIM # | Priority Dependency | Notes |
|---|
| FlsTst_CrcIRQ | 19 | | Must be IRQ and Category 2 |
| | | |
Manual Configuration Changes
Integration
<Mention any global variable that this component requires for other components>
<Mention any global variable that this component requires for other components>
Specific Include Path present
<Yes>
Runnable Scheduling
This section specifies the required runnable scheduling.
| Runnable | Scheduling Requirements | Privileged Mode | Trigger |
|---|
| FlsTst_Init() | Must be executed prior to using FlsTst_MainFunction() | Required | Init* |
| FlsTst_MainFunction() | Scheduling cycle can influence the time to complete the background test interval. A new test block is started only during the invocation of the MainFunction, so an excessively large period between MainFunction calls will extend the time for a test interval to complete. | | Cyclic |
| FlsTst_CrcIrq() | Scheduled via hardware IRQ. The integrator must enable the interrupt source configured in the Os before this runnable can be triggered by the hardware. | | IRQ on signature failure |
* Can be called during run time to change block test configuration if required.
Memory Mapping
Mapping
| Constant | Notes |
|---|
| FLSTST_START_SEC_VAR_CLEARED_8 | |
| FLSTST_START_SEC_VAR_16 | |
| FLSTST_START_SEC_VAR_CLEARED_UNSPECIFIED | |
| FLSTST_START_SEC_VAR_UNSPECIFIED | |
| FLSTST_START_SEC_CODE | |
| FLSTST_START_SEC_CONST_UNSPECIFIED | |
* Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.
Usage
Table 1: ARM Cortex R4 Memory Usage
| Feature | RAM | ROM |
|---|
| Full driver | | |
NvM Blocks
| Block Name |
|---|
| <NvM Block Info> |
Note : Size of the NVM block if configured in developer
Compiler Settings
Preprocessor MACRO
<Define all the preprocessor Macros needed and conditions when needed>.
Optimization Settings
Revision Control Log
| Rev # | Change Description | Date | Author Initials |
| 1 | Initial version | | JJW |
| 2 | Updated integration process description to reference use of Integrate.bat | 09/18/12 | JJW |
| 3 | Updated to latest template, other misc cleanup. | 06-Jan-14 | KMC |
6 - FlsTst_MDD
Module --
High-Level Description
This is module implements the FLASH Memory testing requirements specified in “EA3.x FDD 32 - uC Diagnostics 000D” according to the AUTOSAR “Specification of Flash Test v1.2.0 ” API definition. This SWC is TI TMS570 target specific.
This module extends the AUTOSAR API definition by including a hardware Self Test function and including support for hardware IRQ’s.
Diagram – Function Data Sharing
This diagram shows all data that is shared between functions within the module.
(Note – If no data is shared between functions, the Text “No Shared Data” can be used in place of a graphic. Also note that init functions need not be shown unless they compute non-zero data to be used by other functions in the module).
Diagram – Function (Name)
This diagram describes the functional characteristics and data flow of a given function.
(Note – This is not mandatory, only used where a graphical representation helps explain the function. It is left to the author’s discretion. New headers of this level (Level 3) should be created for each function.
Variable Data Dictionary
For details on module input / output variable, refer to the Data Dictionary for the application. Input / output variable names are listed here for reference.
(Note: Full variable names required in table.)
(Note: All global variables including End Of Line data used should be shown here)
| Module Inputs | Module Outputs |
|---|
| <VarName_Units_Type> | <VarName_Units_Type> |
| |
Module Internal Variables
This section identifies the name, range and resolutions for module specific data created by this module. If there are no range restrictions on the variable, the term “FULL” is placed into the table for legal range.
| Variable Name | Resolution | Legal Range (min) | Legal Range (max) | Software Segment |
|---|
| <None> | | | | |
| | | | |
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) |
|---|
(Name given for the user defined typdef of type struct/union) (Variable name qualified similar to all other variables) | (Variable name qualified similar to all other variables) | as other variables | | |
| (Variable name qualified similar to all other variables) | | | |
Constant Data Dictionary
Calibration Constants
This section lists the calibrations used by the module. For details on calibration constants, refer to the Data Dictionary for the application.
Program(fixed) Constants
Embedded Constants
All embedded constants whose values are provided in Eng units will be evaluated to the equivalent counts by using the FPM_InitFixedPoint_m() macro within the #define statement.
Local
| Constant Name | Resolution | Units | Value |
|---|
| <None> | | | |
| | | |
Global
This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application.
Module specific Lookup Tables Constants
(This is for lookup tables (arrays) with fixed values, same name as other tables)
| Constant Name | Resolution | Value | Software Segment |
|---|
| None | | | |
Functions/Macros used by the Sub-Modules
Library Functions / Macros
The library and functions / Macros that are called by the various sub modules are identified below,
<None>
Data Hiding Functions
<None>
Global Functions/Macros Defined by this Module
Global Function #1
| Function Name | (Exact name used) | Type | Min | Max | UTP Tol. |
|---|
| Arguments Passed | (if none, write None) | | | | |
| (Insert more rows for additional passed arguments) | | | | |
| Return Value | (if no value returned, write N/A) | | | | |
Description
(Place flowchart/design for local function)
Local Functions/Macros Used by this MDD only
Local Function #1
| Function Name | (Exact name used) | Type | Min | Max | UTP Tol. |
|---|
| Arguments Passed | (if none, write None) | | | | |
| (Insert more rows for additional passed arguments) | | | | |
| Return Value | (if no value returned, write N/A) | | | | |
Description
(Place flowchart/design for local function)
Software Module Implementation
Runtime Environment (RTE) Initial Values
This section lists the initial values of data written by this module but controlled by the RTE. After RTE initialization, the data in this table will contain these values.
Initialization Functions
(Note: For multiple init functions, insert new headers at the “Header 2” level – subset of “5.1 Initialization Functions” and follow the same sub-section design shown below)
Init: _L_Init(n)
Design Rationale
(Add design rationale specifically related to this FUNCTION. If none required, place the text “None”)
Module Outputs
(Initialize all module outputs in this section)
Module Internal
(Initialize all module internal variables in this section)
Periodic Functions
(Note: For multiple periodic functions, insert new headers at the “Header 2” level – subset of “5.2 Periodic Functions” and follow the same sub-section design shown below)
Per: _L_Per(n)
Design Rationale
(Add design rationale specifically related to this FUNCTION. If none required, place the text “None”)
Program Flow Start
(If program flow is required by the module, the function to store the unique identifier to a temporary variable is done here – start of the function)
(If not required based on design, insert text “None”)
(Processing of function)………
(Breakdown the function into smaller sections to add clarity to the design).
Store Local copy of outputs into Module Outputs
(If not required based on design, insert text “None”)
Program Flow End
(If program flow is required by the module, the function to add the temporary variable to the global accumulator is done here)
Fault Recovery Functions
(Note: For multiple functions, insert new headers at the “Header 2” level – subset of “5.3 Fault Recovery Functions” and follow the same sub-section design shown below)
FaultRec: _L_FaultRec(n)
Design Rationale
(Add design rationale specifically related to this FUNCTION. If none required, place the text “None”)
Program Flow Start
(If program flow is required by the module, the function to store the unique identifier to a temporary variable is done here – start of the function)
(If not required based on design, insert text “None”)
(Processing of function)………
(Breakdown the function into smaller sections to add clarity to the design).
Store Local copy of outputs into Module Outputs
(If not required based on design, insert text “None”)
Program Flow End
(If program flow is required by the module, the function to add the temporary variable to the global accumulator is done here)
Shutdown Functions
(Note: For multiple functions, insert new headers at the “Header 2” level – subset of “5.4 Shutdown Functions” and follow the same sub-section design shown below)
Shtdn: _L_Shtdn(n)
Design Rationale
(Add design rationale specifically related to this FUNCTION. If none required, place the text “None”)
Program Flow Start
(If program flow is required by the module, the function to store the unique identifier to a temporary variable is done here – start of the function)
(If not required based on design, insert text “None”)
(Processing of function)………
(Breakdown the function into smaller sections to add clarity to the design).
Store Local copy of outputs into Module Outputs
(If not required based on design, insert text “None”)
Program Flow End
(If program flow is required by the module, the function to add the temporary variable to the global accumulator is done here)
Interrupt Functions
(Note: For multiple functions, insert new headers at the “Header 2” level – subset of “5.5 Interrupt Functions” and follow the same sub-section design shown below)
Isr: _L_Isr(n)
Design Rationale
(Add design rationale specifically related to this FUNCTION. If none required, place the text “None”)
(Processing of the ISR function)…..
(Note: Multiple headings can be used to break apart the functionality)
Serial Communication Functions
(Note: For multiple functions, insert new headers at the “Header 2” level – subset of “5.6 Serial Communication Functions” and follow the same sub-section design shown below)
SComm: _L_SComm(n)
Design Rationale
(Add design rationale specifically related to this FUNCTION. If none required, place the text “None”)
Program Flow Start
(If program flow is required by the module, the function to store the unique identifier to a temporary variable is done here – start of the function)
(If not required based on design, insert text “None”)
(Processing of function)………
(Breakdown the function into smaller sections to add clarity to the design).
Store Local copy of outputs into Module Outputs
(If not required based on design, insert text “None”)
Program Flow End
(If program flow is required by the module, the function to add the temporary variable to the global accumulator is done here)
Execution Requirements
Execution Sequence of the Module
(Describe in words relevant details about the execution sequence of the different sub modules.)
Execution Rates for sub-modules called by the Scheduler
This table serves as reference for the Scheduler design
| Function Name | Calling Frequency | System State(s) in which the function is called |
|---|
| <None> | | |
Execution Requirements for Serial Communication Functions
| Function Name | Sub-Module called by (Serial Comm Function Name) |
|---|
| <None> | |
Memory Map Definition Requirements
Sub Modules (Functions)
This table identifies the software segments for functions identified in this module.
| Name of Sub Module | Software Segment |
|---|
| |
Local Functions
This table identifies the software segments for local functions identified in this module.
| Name of Sub Module | Software Segment |
|---|
| |
Known Issues / Limitations With Design
(Item #1)
Revision Control Log
| Item # | Rev # | Change Description | Date | Author Initials |
|---|
| 1 | 1.0 | Initial creation | 7/4/2012 | JJW |
7 - OsErrCallouts_MDD
High-Level Description
OsErrCallouts provides the error hook functions ErrorHook() and ProtectionHook() to provide diagnostic information for certain errors that result in calls to these hooks.
Diagram – Function Data Sharing
No Shared Data
Variable Data Dictionary
For details on module input / output variable, refer to the Data Dictionary for the application. Input / output variable names are listed here for reference.
(Note: Full variable names required in table.)
(Note: All global variables including End Of Line data used should be shown here)
| Module Inputs | Module Outputs |
|---|
| None | |
| |
Module Internal Variables
This section identifies the name, range and resolutions for module specific data created by this module. If there are no range restrictions on the variable, the term “FULL” is placed into the table for legal range.
| Variable Name | Resolution | Legal Range (min) | Legal Range (max) | Software Segment |
|---|
| None | | | | |
| | | | |
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) |
|---|
| <None> | | | | |
| | | | |
Constant Data Dictionary
Calibration Constants
This section lists the calibrations used by the module. For details on calibration constants, refer to the Data Dictionary for the application.
Program(fixed) Constants
Embedded Constants
All embedded constants whose values are provided in Eng units will be evaluated to the equivalent counts by using the FPM_InitFixedPoint_m() macro within the #define statement.
Local
| Constant Name | Resolution | Units | Value |
|---|
| None | | | |
Global
This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application.
| Constant Name |
|---|
| UNUSEDINTERRUPT |
| STACKOVERWRITE |
| MPUVIOLATION |
| osdErrSOStackOverflow |
| osdErrYOStackOverflow |
| osdErrUEUnhandledException |
Module specific Lookup Tables Constants
(This is for lookup tables (arrays) with fixed values, same name as other tables)
| Constant Name | Resolution | Value | Software Segment |
|---|
| <None> | | | |
Functions/Macros used by the Sub-Modules
Library Functions / Macros
The library and functions / Macros that are called by the various sub modules are identified below,
RednRpdShtdn()
Data Hiding Functions
OSErrorGetosCANError()
Global Functions/Macros Defined by this Module
Global Function #1
| Function Name | ErrorHook | Type | Dir. | Min | Max | UTP Tol. |
| Arguments Passed | ErrorCode | StatusType | | N/A | N/A | |
| Return Value | N/A | | | | | |
Design Rationale
When the error was an unhandled exception, reset with a reset cause indicating unexpected interrupt. Currently does no handling of other errors.
Description
Global Function #2
| Function Name | ProtectionHook | Type | Dir. | Min | Max | UTP Tol. |
| Arguments Passed | ErrorCode | StatusType | | N/A | N/A | |
| Return Value | <has return value defined but function does not return> | ProtectionReturnType | | PRO_SHUTDOWN | |
Design Rationale
When the protection violation was a stack fault, reset with a reset cause of STACKOVERWRITE. For any other protection violation, reset with a reset cause of MPUVIOLATION.
Description
Local Functions/Macros Used by this MDD only
None
Software Module Implementation
Runtime Environment (RTE) Initial Values
This section lists the initial values of data written by this module but controlled by the RTE. After RTE initialization, the data in this table will contain these values.
Initialization Functions
None
Periodic Functions
None
Fault Recovery Functions
None
Shutdown Functions
None
Interrupt Functions
None
Serial Communication Functions
None
Execution Requirements
None.
Memory Map Definition Requirements
Sub Modules (Functions)
This table identifies the software segments for functions identified in this module.
| Name of Sub Module | Software Segment |
|---|
| ErrorHook | APPLCB_CODE |
| ProtectionHook | APPLCB_CODE |
Local Functions
This table identifies the software segments for local functions identified in this module.
| Name of Local Function | Software Segment |
|---|
| None | |
| |
Known Issues / Limitations With Design
None
Revision Control Log
| Item # | Rev # | Change Description | Date | Author Initials |
| 1 | 1.0 | Initial Revision | 6/26/2013 | KMC |
8 - uDiag_Design_Review
Overview
Summary Sheet
Davinci Files
Source Code CCRM
Source Code ClockMonitor
Source Code ECC
Source Code ESM
Source Code IOMM
Source Code Parity
Source Code ResetHandler
Source Code StaticRegs
Source Code VIM
Source Code RednRpdShtdn
Source Code LossOfExec
QAC CCRM
QAC ClockMonitor
QAC ECC
QAC ESM
QAC IOMM
QAC Parity
QAC ResetHandler
QAC StaticRegs
QAC VIM
QAC RednRpdShtdn
QAC LossOfExec
Integration Manual uDiag
Integration Manual FlsTst
Sheet 1: Summary Sheet
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
 | Peer Review Summary Sheet |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Component Name: |
|
|
| kzshz2:
Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy
Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request.
TMS570_uDiag |
| Component Revision: |
|
|
| kzshz2:
Intended Use: Identify which Synergy revision of this component is being reviewed
Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request.
FDD32B_TMS570_uDiag_000.23 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
|
| kzshz2:
Intended Use: Identify the developer who made the change(s)
Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards.
Kathleen Creager |
| Change Request ID: |
|
|
| 11157, 11158. 11176 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed.
Rationale: This will be good information to know when ensuring appropriate reviews have been completed.
Modified File Types: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
 |
 |
 |
 |
 |
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers, what they reviewed, and if the reviewed changes have been approved to release the code for testing. Comments here should be at a highlevel, the specific comments should be present on the specific review form sheet.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
ADD DR Level
Move reviewer and approval to individual checklist form
Review Checklist Summary: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Reviewed: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | MDD |
|
|
| X | Source Code |
|
|
|
| | Data Dictionary |
|
|
| X | QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| X | Integration Manual |
|
|
| X | Davinci Files (Generate files) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Comments: |
|
| 1) Most modules in this component do not have an MDD. CR 10409 written to create MDDs. |
|
|
|
|
|
|
| 2) Reviewed changes only. |
|
|
|
|
|
|
| 3) Reviewed the ten changed and one new source files (out of 21 source files total) and their QAC results, plus the |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| changed DaVinci files, generate files, include files, and integration manuals (uDiag and FlsTst) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| NOTE QAC ESM and QAC VIM tabs for future actions to be considered on next rev of component |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| NOTE that there are multiple Cd_uDiagxxx.c source files that use RTE functions, but only one Cd_uDiag component. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Consider writing a continuous improvement CR to restructure the component. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Guidelines:
- The reviews should be performed over the portions of the component that were modified as a result of the Change Request. (Note: If this peer review form was not
completed for pervious versions of this component, the Change Owner should review the entire component and complete the checklist in its entirety prior and check
the form into Syngery. This should be done prior to reviewing the modifications for this Change Result)
- The Change Owner is responsible for completing the entire checklist (Pre and Group review items) prior holding the initial group review.
- New components should include FDD Owner and Intergator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Select "Yes" and add "N/A" to the comments for checklist items that are not applicable for this change
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 2: Davinci Files
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Davinci Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
| Pre-review checklist for change owners | DCF: Latest StdDef imported |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| imported StdDef_2.34 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| DCF: Only StdDef Port types are used (if not |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
| add justification) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| DCF: All unused definitions removed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| *Cfg.arxml.TT: Verfied Davinci Configurator imported the |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| change correctly |
| kzshz2:
Either a generic sandbox or a baselined integration project can be used to verify
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| *Cfg.h.TT: Verfied Davinci Configurator generates |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| the configuration header(s) file correctly |
|
|
|
|
| kzshz2:
Either a generic sandbox or a baselined integration project can be used to verify
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review for review board | All changed files have been compared against previous |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
| versions (If available) |
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present. This is for text files only, not binary or GUIs
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| DCF:Automated validation check is performed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| DCF: Inputs/Outputs match names from requirements |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| DCF: Inputs/Outputs configuration paremeters |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
| reviewed | kzshz2:
Intended Use: All changed inputs have been reviewed to ensure configuration parameters (i.e. Buffered vs Direct read/writes) are correct.
This includes signal grouping when signal consistency is required by the FDD
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| DCF: Sender/Reciever Ports type and default values |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
| macth their corresponding ports (internal/external) |
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if all the Sender/Reciever ports are compatibale with there connecting ports.
Rationale: This will help to avoid errors when this component is being integrated into a project.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| DCF: Ports prototype and default values |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
| macth their corresponding ports (internal/external) |
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if all the Server/Client ports are compatibale with there connecting ports.
Rationale: This will help to avoid errors when this component is being integrated into a project.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| DCF: Server runnable variables are using direct |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
| read/writes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| DCF: Runnable calling frequencies match requirements |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| FDD does not specify frequencies |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 3: Source Code CCRM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagCCRM.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
5 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 4: Source Code ClockMonitor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagClockMonitor.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
10 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 5: Source Code ECC
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagECC.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
8 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 6: Source Code ESM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagESM.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
7 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 7: Source Code IOMM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagIOMM.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 8: Source Code Parity
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagParity.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
7 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 9: Source Code ResetHandler
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagResetHandler.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
7 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 10: Source Code StaticRegs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagStaticRegs.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
8 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 11: Source Code VIM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagVIM.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
12 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/13/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 12: Source Code RednRpdShtdn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
RednRpdShtdn.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 13: Source Code LossOfExec
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which .asm, .c, or .h file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagLossOfExec.c |
| Source File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Design Document Name: |
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
| MDD Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the MDD this source file was written against.
Rationale: Needed for traceability between source code and MDD
N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Data Dictionary Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review.
Rationale: Needed for traceability between source code and DD
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
Pre-review checklist
(change owners only) | Analysis performed for divide by zero |
|
|
|
|
| kzshz2:
Intended Use: To confirm this defensive coding strategy has been taken into consideration
Rationale: Necessary since currently there is no place this is documented
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standard followed |
| X | |
| Comments: |
|
| as checked by QAC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Naming Convention followed |
|
|
| X | |
| Comments: |
|
| for new/changed code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All buffered outputs are written in every path |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| NA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code compared vs requirements (Document or Model) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify if previous version was compared and only the expected change(s) was present.
Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.
| X | |
| Comments: |
|
| Compared against FDD; |
|
|
|
|
|
|
|
|
|
|
|
|
|
| however FDD needs updates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs (RTE/Non-RTE) Initialized |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Global Outputs are limited to the legal range defined |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| in the FDD Data dictionary |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No Compiler Errors verified |
|
|
| kzshz2:
Intended Use: To confirm the appropriate variable name formats have been used.
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Type Casting and Fix Point Macros use reviewed |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function prototype and passed parameters are |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
| N/A for this review |
|
|
|
|
|
|
|
| consistent |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/13/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 14: QAC CCRM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagCCRM.c |
|
| Source File Revision: |
|
|
| 5 |
|
| Module |
| 1 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 15: QAC ClockMonitor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagClockMonitor.c |
|
| Source File Revision: |
|
|
| 10 |
|
| Module |
| 2 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 16: QAC ECC
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagECC.c |
|
| Source File Revision: |
|
|
| 8 |
|
| Module |
| 3 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 17: QAC ESM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagESM.c |
|
| Source File Revision: |
|
|
| 7 |
|
| Module |
| 4 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| QAC does not recognize CODE_STATE pragma (from a previous revision of the component) -- but verified that the pragma is recognized and used |
|
| as expected by the compiler. Consider further investigation of the QAC warning in a later rev of the component. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 18: QAC IOMM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagIOMM.c |
|
| Source File Revision: |
|
|
| 6 |
|
| Module |
| 5 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 19: QAC Parity
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagParity.c |
|
| Source File Revision: |
|
|
| 7 |
|
| Module |
| 6 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 20: QAC ResetHandler
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagResetHandler.c |
|
| Source File Revision: |
|
|
| 7 |
|
| Module |
| 7 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 21: QAC StaticRegs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagStaticRegs.c |
|
| Source File Revision: |
|
|
| 8 |
|
| Module |
| 8 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 22: QAC VIM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagVIM.c |
|
| Source File Revision: |
|
|
| 12 |
|
| Module |
| 9 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Warning for extern declaration of D_VIMTABLENAME_CNT_U32 -- not a new warning, has existed for previous versions of the component -- |
|
| moved declaration to uDiag.h |
|
| Warning for externally linked declaration of VIM_Fallback -- not a new warning, has existed for previous versions of the component -- |
|
| this function could maybe be declared static but will require testing -- consider in next version of component |
|
| QAC does not recognize CODE_STATE pragma (from a previous revision of the component) -- but verified that the pragma is recognized and used |
|
| as expected by the compiler. Consider further investigation of the QAC warning in a later rev of the component. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/13/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 23: QAC RednRpdShtdn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
RednRpdShtdn.c |
|
| Source File Revision: |
|
|
| 1 |
|
| Module |
| 10 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 24: QAC LossOfExec
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (QAC Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Module Name: |
|
| kzshz2:
Intended Use: Identify which .c file is being analyzed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiagLossOfExec.c |
|
| Source File Revision: |
|
|
| 6 |
|
| Module |
| 11 | of | 21 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Compliance Document Version: |
|
|
|
|
| unreleased |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner.
Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed
Brief Summary of Changes (In Results or Tool): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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) |
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify which version of the QAC Subproject was used and if any of the personalities may have changed.
Rationale: Will help ensure this is factored into evaluating the results
| X | |
| Comments: |
|
| QAC_6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Contract Folder's header files are appropriate |
|
|
|
|
|
| kzshz2:
Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed.
Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| G Group-review Checklist (review board) | 100% Compliance to the MISRA Compliance Document | X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/13/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 25: Integration Manual uDiag
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Integration Manual Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Integration Manual Name: |
|
|
|
| kzshz2:
Intended Use: Identify which file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
Cd_uDiag_Integration_Manual |
|
| Integration Manual Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the integration manual has been reviewed.
Rationale: Required for traceability between the MDD and review. Auditors will likely require this.
4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Latest template used |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Changes Highlighted (for Integrator) |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Only made updates related to the changes made in this rev of the component, and some cleanup moving FlsTst info to FlsTst Integration Manual. Cd_uDiag |
|
| Integration manual is incomplete. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 26: Integration Manual FlsTst
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 2.0 | 26-Aug-13 |
| Peer Review Meeting Log (Integration Manual Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Integration Manual Name: |
|
|
|
| kzshz2:
Intended Use: Identify which file is being reviewed
Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form.
FlsTst_Integration_Manual |
|
| Integration Manual Revision: |
|
|
|
| kzshz2:
Intended Use: Identify which version of the integration manual has been reviewed.
Rationale: Required for traceability between the MDD and review. Auditors will likely require this.
3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Yes | No |
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
| Group-review Checklist (review board) | Telelogic Synergy version matches header |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Latest template used |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Changes Highlighted (for Integrator) |
|
|
|
|
|
|
|
|
| X | |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Updated to latest rev of the integration manuaol template. Moved some FlsTst info from Cd_uDiag integration manual to FlsTst integration manual. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
Group Review Level:
There are four Design Review States that a document may have as follows:
DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required.
DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review.
DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer.
DR4 – The document has passed all peer reviews and is ready for release.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Kathleen Creager |
| Review Date : |
|
| 01/10/14 |
| Group Review Level: |
|
|
| DR4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Selva Sengottaiyan |
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|