The purpose of this document is to describe the design of the Architecture Global Parameters component including the selection criteria for items to be included in the component and the method used for specifying the values of the items.

ArchGlbPrm Design

constants

The ArchGlbPrm component contains global constants that are either “mathematical” (e.g. the value of pi) or software-oriented (e.g. the value to be used as the zero threshold for float32 comparisons) in nature. The constants are defined in AR999A_ArchGlbPrm_DataDict.m and implemented as #define statements in “ArchGlbPrm.h”.

float32 Constant specification

For each float32 constant, the number of digits was chosen based on the smallest number of digits needed to give the same float32 representation as the value calculated by Excel. Rationale: this gives the most accurate representation possible for float32, while not containing a misleading number of digits beyond the resolution actually possible with float32.

Example procedure for determining the number of digits to use:

Enter the desired constant in Excel as a formula, e.g. “=PI()/2”

Copy the cell and paste as value into another cell

Select the new cell and copy the displayed value to the clipboard

Paste this value in a IEEE floating point conversion tool; record the single precision floating point representation (in hex), both rounded and unrounded.

Val = the pasted Excel value

X = number of digits in Val

Y = X

Do:

Y = Y - 1

Val1 = Val rounded to Y digits

While ((rounded single float representation of Val == rounded single float representation of Val1) AND
(unrounded single float representation of Val == unrounded single float representation of Val1))

Val2 = Val rounded to Y + 1 digits

Use Val2 as the constant value in the .h and .m files

2 - AR999A_ArchGlbPrm_PeerReview_Design

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 Owner	Confirm that requirements are reviewed and approved PRIOR to the FDP peer review
	Function Owner	Start with latest version of the template for any "first reviews" - Continue to use existing temmplate for re-reviews
	Function Owner	Provide the functional design package (changed documents) to the invited attendees 1-2 working days in advance of review
	Function Owner	Notify the assigned peer reviewer and make sure they are prepared to do their function in the meeting
	Function Owner	Identify necessary attendance and invite to meeting
	Function Owner	Complete the "Author" column information for sections 1 through 3 prior to the review
	Function Owner	Complete the attendance invitation list in section 5
	Function Owner	For Re-reviews only: Complete the column "remarks by author" to identify actions taken to address items found in earlier reviews.

DURING MEETING
	Function Owner	Present document changes to the review team
	Peer Reviewer	Capture attendance of the review
	Peer Reviewer	Capture actions and issues in section 4. Identify issue summary, Document type, Reference (Requirement ID, section number, etc), Defect Type and indicate status as "OPEN"

POST MEETING
	Function Owner	Follow up on all "open" items. Update "Summary of Resolution" to indicate what was done or decided.
	Function Owner	Schedule follow up review OR review open items with peer reviewer and obtain agreement to close
	Peer Reviewer	Close change request in system and confirm all associated tasks are complete. Upload peer review checklist (this document) with any FDP updates

Sheet 2: Technical Review Checklist

Technical Review Checklist - Template Version 02.00.00

Product Name

Electric Power Steering

Electrical Arch.

Review Scope

Defect Type

Numbers

Yes

Closed

Function ID

AR999A_ArchGlbPrm

DataDict.m

Requirement

Rejected

FDD

Long Name

Architecture Global Parameters

Interface

Open

Model

Version that you started from. NOT the version you hope to release. If this will be v1.0.0, enter NA. Starting Baseline

1.1.0

Effort

Design

FMEA

Author

Review Effort(Hrs.)

0.00

Standards

*.m File

Corr+Verf effort(Hrs.)

Documentation

Cal Process

Total Effort (Hrs.)

0.00

Others

Total

Checklist No.

Description of Check

Author: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. Author

Author: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. Reviewer

Author: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewer

Author: Defect type to be selected. Defect Type

Author: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By Author

Author: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status

Section 1: Data Dictionary

Is Filename of Data Dictionary in correct format?

Yes

Is the FDD.Version property correctly updated?

Yes

Is the Data Dictionary Verification report error free?

VerifyDD crashed

Closed

Does FDD Long Name, Short Name, and Description match requirements?

Are all runnables defined?

Do runnables have the correct time step?

Do server runnables correctly define arguments?

Are all clients defined?

Do client definitions match the corresponding server runnable?

Does name and metadata of every signal match its corresponding interface signal?

Do output signal ranges match requirements (check DOOR min/max attributes too)?

Are calibration tables named correctly (e.g. AssiX and AssiY)?

Do all calibrations have correct values for all metadata?

Are calibration tables named correctly (e.g. AssiX and AssiY)?

Is NVM defined in the appropriate number of blocks?

Are constants defined with proper scope (local vs global)?

Yes

Are all dependent constants and calibrations included in one file?

Section 2: Model

Author: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. Author

Author: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. Reviewer

Author: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewer

Author: Defect type to be selected. Defect Type

Author: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By Author

Author: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status

Is filename of model in correct format?

Is Top level of model annotated with Requirements Baseline?

Is the Top level of the model annotated with Tool Dependencies?

Is Top level of model annotated with Change Log or History?

Does the Component shortname match data dictionary FDD metadata?

Is the 2nd level of model free from subsystems that are not Function-Call Subsystems?

Is the 2nd level of model free from arithmetic and logic operations?

Are the Runnable trigger signals named as "call_<Runnable>"?

Does 2nd level of model have a properly updated annotation with name, description, and intended baseline number?

Are all data flow layers free of Function-Call Subsystems and Memory Store blocks?

Does the Model have the confidentiality and copyright information inside all its Subsystems?

Are all the Memory Store blocks for PIM and Display Variables located on the 2nd level of model?

Do all Memory Store blocks for PIM and Display Variables have the "Data store name must resolve to Simulink signal object" setting checked to true?

Is each diagnostic (NTC) capable of being set to "PASS"?

Does non-zero intialization of PIM occur in the function's Init runnable?

Does design properly include Set Ram Block Status when NVM RAM values change?

Does model include appropriate logic for dealing with missing or corrupted NVM data?

Does model execute without errors/warnings after loading NxtrMBDConfig configuration set?

Section 3: Requirements Linking

Author: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. Author

Author: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. Reviewer

Author: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewer

Author: Defect type to be selected. Defect Type

Author: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By Author

Author: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status

Are all requirements links of the format <FDDNumber>_<ObjectID>?

Does requirements HTML report reference only the DOORS module of this component for all links in the design?

Are linked blocks linked to the correct requirements(s)? (watch for problems due to copy/pasted blocks)

Is the list of unlinked blocks acceptable?

Section 4: Model Advisor

Author: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. Author

Author: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. Reviewer

Author: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewer

Author: Defect type to be selected. Defect Type

Author: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By Author

Author: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status

Was Model Advisor run with the correct configuration settings?

Is the Model Advisor rerport free from "Fails".

Are Model Advisor report "Warnings" acceptable?

Section 5: Delivery Package

Author: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. Author

Author: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. Reviewer

Author: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewer

Author: Defect type to be selected. Defect Type

Author: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By Author

Author: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status

Does Design folder contain only the model, data dictionary, and (optionally) a simulation setup script?

Yes

Does Doc folder contain a zipped HTML webview model?

Does Reports folder contain only the data dictionary verification report, zipped Model Advisor report, and zipped requirements traceability report?

Yes

Section 6: Other Issus/Actions Identified

Document

Reference

Summary of resolution

Author: Defect type to be selected. Defect Type

Author: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By Author

Author: 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

4.16

4.17

4.18

4.19

4.20

4.21

4.22

4.23

4.24

4.25

Section 7: APPROVALS

Role

First Review

Date

Attendance

Approval?

Function Owner*

Kathleen Creager

6/23/2015

Yes

Peer Reviewer*

Kevin Derry

Yes

Safety

Software

ESG / Systems

EPDT / CSE

Hardware

Test

Role

Second Review (if required)

Date

Attendance

Approval?

Function Owner*

Peer Reviewer*

<Name>

Safety

Software

ESG / Systems

EPDT / CSE

Hardware

Test

Role

Third Review (if required)

Date

Attendance

Approval?

Function Owner*

Peer Reviewer*

<Name>

Safety

Software

ESG / Systems

EPDT / CSE

Hardware

Test

Role

Fourth Review (if required)

Date

Attendance

Approval?

Function Owner*

Peer Reviewer*

<Name>

Safety

Software

ESG / Systems

EPDT / CSE

Hardware

Test

Role

Add more if necessary

Date

Attendance

Approval?

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

Rev	Change	Author
01.00.05	Added lesson learned #3.5	MDK
01.00.06	Added lesson learned #3.6, 3.7 - Structure and writing of NVM in mfiles and models.	MDK
02.00.00	Combined ESG and Systems into one, compatible with Data_Management 2.13.0 of CreateDD and VerifyDD.	K. Derry