This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Component Design

Component Design

Module Detailled Design

Component Documentation

1 - CM111A_VrfyCritReg

Verify Critical Register

(VrfyCritReg)

FDD #CM111A

1. High Level Description 3

2. Sub-Function In This Document 3

3. Critical Registers 3

3.1. Sub-Function: VrfyCritRegInit1 3

3.1.1. NTCs 3

3.1.2. SAN Linkage 3

3.1.3. Description 4

3.1.4. Rationale 4

3.1.5. Implementation 5

3.2. Sub-Function: VrfyCritRegPer1 6

3.2.1. NTCs 6

3.2.2. SAN Linkage 6

3.2.3. Description 6

3.2.4. Rationale 6

3.2.5. Implementation 6

3.2.6. Verification Method 8

4. Revision Record & Change Approval 8

High Level Description

This document describes the microcontroller configuration for the critical register verification functions. Critical registers are ones whose contained values are considered vital to safety or function (secondary to safety) beyond the protections provided by protection hardware and software.

The functions described herein perform read back and value verification functions. If a mismatch is detected in the result shall be transition to a safe state preceded by non-volatile storage of the specific cause of this decision if possible.

The initial lists of critical registers were obtained by reviewing the recommendations of Renesas’ Safety Application Note ver 1.20.

Some of these recommendations were not followed because they would require masking off of unpredictable bits and some may have been rejected if the particular hardware interface is not used.

Sub-Function In This Document

Below is a list of all sub-functions owned by this document.

Sub-Function NameLink
Check critical registers once at initialization ( VrfyCritRegInit1 )3.1
Check critical registers during periodic updates ( VrfyCritRegPer1 )3.2
Empty Initial Sub-function ( VrfyCritRegInit2 )3.3

Critical Registers

Sub-Function: VrfyCritRegInit1

NTCs

N/A

SAN Linkage

5.2 Read back of configuration static register should be done at start-up [SAN-P1x-0504].

7.2 Read back the static configuration registers shall be done once at start-up [SAN-P1x-0704]. This includes to check that ECC is enabled, error notification to ECM and test registers.

8.2 At startup it shall be checked that the address parity check is enabled by reading back the related control register.

9.2 Read back DFECCCTL and FERRINT registers should be done once at start-up.

10.2 Read back the static configuration register once at start-up shall be done to ensure that the correct values are set [SAN-P1x-1005]. This includes to check that ECC is enabled and error notification to the ECM.

11.2 Read back the static configuration register once at start-up shall be done to ensure that the default settings are correctly set.

13.2 Read back the static configuration register once at start-up shall be done to ensure that the correct values are set. This includes to check that ECC is enabled and error notification to ECM as well [SAN-P1x-1305].

14.2 The control register shall be also read back once after configuration to ensure the CLM is enable [SAN-P1x-

1403].

15.2 In order to confirm the operation of the locking function, the SW shall write "0" to CVMDIAGMEW and CVMFBISTMEW bits and verify that "1" is not overwritten by "0" by reading back CVMDE register [SAN-P1x-1508].

15.2 Moreover static configuration register shall be read-back and verified to ensure that the correct values are

set.

16.2 Static configuration register shall be read back and verified once at start-up to ensure that the related register

have the proper configuration.

25.2 The configuration from the mode register shall be read to confirm that the correct operating mode (normal

mode) has been entered and/or that the proper value has been applied to the external mode pins.

29.2 Field BIST control register shall be read back and verified to ensure that the Field BIST is enabled [SAN-P1x-2902].

31.2 the user shall check that the transfer of the data is carried out without error. This can be done by reading back the option byte register and checking the content.

Description

This sub-function reads values from critical registers and verifies that the stable portion retains the expected value which has been deemed to be critical.

Rationale

This function is intended to be called once per update period so that it can verify that critical registers still hold the values expected. Because an NTC code is set on failure, this function must not be called until after the Diagnostic Manager has run to start the handling of these calls

Caution: In order to record a unique number which will identify which value has failed this test, the number of “periodic” test critical registers must be maintained/communicated to the “initialization” code to use as the starting value for its count.

Implementation

Each entry in the register table shall be read, bitwise masked (an AND operation) with a value specific to the register to handle unused or dynamic bits and compared to the expected value. Any mismatch indicates a non-recoverable error so the code shall set a NTC diagnostic code and stop iterating.

struct NonSysCritRegRec1

{

uint CritRegAdr;

uint CritRegVal;

uint CritRegMask;

}

struct NonSysCritRegRec1 IninCritReg8BitChk[NROFININCRITREG8BIT_CNT_U16];

struct NonSysCritRegRec1 IninCritReg16BitChk[NROFININCRITREG16BIT_CNT_U16];

struct NonSysCritRegRec1 IninCritReg32BitChk[NROFININCRITREG32BIT_CNT_U16];

struct NonSysCritRegRec1 PerCritReg8BitChk[NROFPERCRITREG8BIT_CNT_U16];

struct NonSysCritRegRec1 PerCritReg16BitChk[NROFPERCRITREG16BIT_CNT_U16];

struct NonSysCritRegRec1 PerCritReg32BitChk[NROFPERCRITREG32BIT_CNT_U16];

void VrfyCritRegInit1( void )

{

temp boolean CritRegInitTestPassd = TRUE;

//CritRegFltTyp = 0 when there is no error, CritRegFltTyp = 1 when there is a non-system critical //register error, CritRegFltTyp = 2 when there is a system critical error

uint CritRegFltTyp = 0;

//If there is one bad comparison no other critical registers need to be verified

//configure IninCritReg#BitChk as a trusted function because it needs to run in supervisor mode

For each IninCritReg#BitChk[] struct instance, loop over all “init” critical register values until CritRegFltTyp != 0;

{

Read the register’s value,

mask the register’s value with the mask value for this register;

if (the masked value != expected value)

CritRegFltTyp = 1;

else

Nothing;

}

//configure SysCritRegIninChk as a trusted function because it needs to run in supervisor mode

For each SysCritRegIninChk, verify all “init” critical register values until CritRegFltTyp != 0;

{

Read the register’s value,

mask the register’s value with the mask value for this register;

if (the masked value != expected value)

SysCritRegInitTestPassd = FALSE;

CritRegFltTyp = 2;

else

Nothing;

}

if (CritRegFltTyp = 0)

SetNtcSts( NtcNr1.NTCNR_0x20, 0, NtcSts1.NTCSTS_PASSD, 0);

else

SetNtcSts( NtcNr1.NTCNR_0x20, CritRegFltTyp, NtcSts1.NTCSTS_FAILD, 0);

}

Sub-Function: VrfyCritRegPer1

Return to sub-function list link: Sub-Function In This Document

NTCs

Critical Register Verification Fault NTC #0x20.

SAN Linkage

4.5.1 For PBG0A the customer should ensure that the guard setting settings are not
accidently changed (e.g. periodic check of the protection setting register, MPU and so on).

Description

This sub-function reads values from critical registers and verifies that the stable portion retains the expected value which has been deemed to be critical.

Rationale

This function is intended to be called once per update period so that it can verify that critical registers still hold the values expected.

Implementation

Each entry in the register table shall be read, bitwise “ANDed” with a mask specific to the register and compared to the expected value. Any mismatch indicates a non-recoverable error so the code shall set an NTC code.

void VrfyCritRegPer1( void )

{

temp boolean CritRegPerTestPassd = TRUE;

//CritRegFltTyp = 0 when there is no error, CritRegFltTyp = 1 when there is a non-system critical //register error, CritRegFltTyp = 2 when there is a system critical error

CritRegFltTyp = 0

//If there is one bad comparison no other critical registers need to be verified

//configure PerCritReg#BitChk as a trusted function because it needs to run in supervisor mode

For each PerCritReg#BitChk[] struct instance, loop over all “periodic” critical register values until CritRegFltTyp != 0;

{

Read the register’s value,

mask the register’s value with the mask value for this register;

if (the masked value != expected value)

CritRegFltTyp = 1;

else

Nothing;

}

//configure SysCritRegIninChk as a trusted function because it needs to run in supervisor mode

For each SysCritRegPerChk, verify all “init” critical register values until CritRegFltTyp != 0;

{

Read the register’s value,

mask the register’s value with the mask value for this register;

if (the masked value != expected value)

CritRegFltTyp = 2;

else

Nothing;

}

if (CritRegFltTyp = 0)

SetNtcSts( NtcNr1.NTCNR_0x20, 0, NtcSts1.NTCSTS_PASSD, 0);

else

SetNtcSts( NtcNr1.NTCNR_0x20, CritRegFltTyp, NtcSts1.NTCSTS_FAILD, 0);

}

Periodic

Iteration period T =10 msec second.

Verification Method

N/A

Revision Record & Change Approval

RevDateChange Control #DrwChange Description
01.00.0001/14/20162772ECInitial Release
02.00.0003/28/20164992ECRestore separate init entry and masks, both set NTC once per entry with second parameter being index to the problem register
02.01.0004/07/20164992SK

Deleted Init2 because we already have an RTE Init1.

Updated Init1 and Per1 to show different parameter byte info for different register index.

02.02.0004/20/20165444GM

Add structure definitions for 8bit, 16bit and 32bit non-system critical register check.

Add separate definition for system critical register check.

Manage system and non-system critical register faults with different NTC parameter bits.

2 - CM111A_VrfyCritReg_CheckList

Nexteer_Template_V1.0

Overview

Peer Review Instructions
Technical Review Checklist
Template Change Log


Sheet 1: Peer Review Instructions

Instructions for Functional Design Package Peer Review




PRE-MEETING


Function OwnerConfirm that requirements are reviewed and approved PRIOR to the FDP peer review

Function OwnerStart with latest version of the template for any "first reviews" - Continue to use existing temmplate for re-reviews

Function OwnerProvide the functional design package (changed documents) to the invited attendees 1-2 working days in advance of review

Function OwnerNotify the assigned peer reviewer and make sure they are prepared to do their function in the meeting

Function OwnerIdentify necessary attendance and invite to meeting

Function OwnerComplete the "Author" column information for sections 1 through 3 prior to the review

Function OwnerComplete the attendance invitation list in section 5

Function OwnerFor Re-reviews only: Complete the column "remarks by author" to identify actions taken to address items found in earlier reviews.



DURING MEETING


Function OwnerPresent document changes to the review team

Peer ReviewerCapture attendance of the review

Peer ReviewerCapture actions and issues in section 4. Identify issue summary, Document type, Reference (Requirement ID, section number, etc), Defect Type and indicate status as "OPEN"



POST MEETING


Function OwnerFollow up on all "open" items. Update "Summary of Resolution" to indicate what was done or decided.

Function OwnerSchedule follow up review OR review open items with peer reviewer and obtain agreement to close

Peer ReviewerClose change request in system and confirm all associated tasks are complete. Upload peer review checklist (this document) with any FDP updates

Sheet 2: Technical Review Checklist

Technical Review Checklist - Template Version 01.00.09







Product NameElectric Power SteeringElectrical Arch.4Review ScopeDefect TypeNumbers




YesClosedFR
Function NameCM111A_VrfyCritRegVersion2.2.0EA4#5444Requirement0




NoRejectedFDD
AuthorGerald McCann

Interface0




NAOpenModel


EffortDesign0






FMEA


Review Effort(Hrs.)0.50Standards0






*.m File


Corr+Verf effort(Hrs.)
Documentation0






Cal Process


Total Effort (Hrs.)0.50Others0













Total0







Checklist No.Description of CheckAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. ReviewerAuthor: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewerAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







1Section 1: TECHNICAL CHECK













1.1Confirm that all signal inputs into the FDP (Functional Design Package) are contained within and exactly named as the "Available_Nexteer_Signals.m" states.NANA











1.2Confirm any removed signal inputs from the design have been removed from the "Available_Nexteer_Signals.m" file.NANA











1.3Confirm all signals and parameters (outputs, calibrations, constants, non-volatile memory) used in the *.m file and the design conform to the AutoSAR naming convention documentation.YesYes











1.4Confirm *.m file has been provided to the "Available_Signal_Names" Author.NoNo











1.5Confirm Electrical Systems interface map is updated to reflect the FDP (signal IO)NANA











1.6Confirm that Static Register evaluation has been completed and updated for any register data that is written to.NANA











1.7Have calibration default values been reviewed for correctness?NANA











2Section 2: Safety CHECKAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewerAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







2.1Confirm that the functional DFMEA is up to date based on the design in the current package.NANA











2.2Confirm that Safety requirements (ASIL A - D) are referenced in the design documents.YesYes











3Section 3: Lessons LearnedAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewerAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







3.01Have functions depending upon system state been reviewed for need to be executed at the 2ms rate to avoid system lag issues?YesYes











3.02Have all diagnostics (NTCs) been confirmed to show logic to invoke a diagnostic "PASS" for control of the status byte at the customer level.YesYes











3.03Has the requirements traceability steps used the RMI steps as defined in the FDD authoring spec to generate the traceability report?NANA











3.04Has the requirements traceability report been verified to only contain ONLY requirements from the FR.NANA











3.05Confirm that all PIM that does NOT have an initialization value of zero is initialized in an INIT function.NANA











3.06Confirm if NVM is used, the NVM is defined in structuresNANA











3.07If the function uses NVM, confirm that the m file uses the SetBlockStatus to indicate a write at powerdownNANA











3.08Confirm NTCs are not set within an IRQ (not related to the typical periodic OS)YesYes











3.09Confirm NTCs are not set or read in a periodic rate faster than 2 ms (ex. Motor Control Loop)YesYes











3.10Constants check: Do all constants have the correct scope (local, global) and are they defined in the correct location (this FDD, ES/SF/AR999)?NANA











3.11Confirm all calibrations are required (ie they cannot be constants)NANA











4Section 4: Issues / Actions IdentifiedDocumentReferenceSummary of resolutionAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







4.1














4.2














4.3














4.4














4.5














4.6














4.7














4.8














4.9














4.10














4.11














4.12














4.13














4.14














4.15














5Section 5: APPROVALS













RoleFirst ReviewDateAttendanceApproval?










Function Owner*Gerald McCann4/25/2016YesYes










Peer Reviewer*Samanth KumaraswamyYes










EPDT Engineer












ES Engineer
No










Software LeadSelva, AvinashNo










Hardware Lead












Test Lead












Safety Lead












RoleSecond Review (if required)DateAttendanceApproval?










Function Owner*<Owner Name>













Peer Reviewer*<Name>











EPDT Engineer<Name - if invited>











ES Engineer<Name - if invited>











Software Lead<Name - if invited>











Hardware Lead<Name - if invited>











Test Lead<Name - if invited>











Safety Lead<Name - if invited>











RoleSecond Review (if required)DateAttendanceApproval?










Function Owner*<Owner Name>













Peer Reviewer*<Name>











EPDT Engineer<Name - if invited>











ES Engineer<Name - if invited>











Software Lead<Name - if invited>











Hardware Lead<Name - if invited>











Test Lead<Name - if invited>











Safety Lead<Name - if invited>











RoleFourth Review (if required)DateAttendanceApproval?










Function Owner*<Owner Name>













Peer Reviewer*<Name>











EPDT Engineer<Name - if invited>











ES Engineer<Name - if invited>











Software Lead<Name - if invited>











Hardware Lead<Name - if invited>











Test Lead<Name - if invited>











Safety Lead<Name - if invited>











RoleAdd more if necessaryDateAttendanceApproval?










































P.S.:Yes indicates adherence














No indicates non-adherence, reviewer shall provide suitable comments at the end of this document for each point.














NA indicates not applicable














Sheet 3: Template Change Log

RevChangeAuthor
01.00.05Added lesson learned #3.5MDK
01.00.06Added lesson learned #3.6, 3.7 - Structure and writing of NVM in mfiles and models.MDK
01.00.07Clarified 3.6 and 3.7
Added lessons learned for NTCs not being set in IRQs or periodics faster than 2ms/
MDK
01.00.08Added section 1.6 to look for critical static register analysisMDK
01.00.09Added two checks - default cals and are all cals really required to be a calibrationMDK
02.00.00Restore separate init entry and masks, both set NTC once per entry with second parameter being index to the problem registerEC