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

Return to the regular view of this page.

Debug Functions

Debug Functions

1 - Component Design

Component Design

Component Documentation

Reports

1.1 - DF001A_FltInj_Design_PeerReviewChkList

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 5 prior to the review

Function OwnerComplete the attendance invitation list in section 7

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 6. 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 02.02.00







Product NameElectric Power SteeringElectrical Arch.4Review ScopeDefect TypeNumbers




YesClosedFR
Function IDDF001A_FltInj

Added one new constant to data dicationary. No model change.Requirement0




NoRejectedFDD
Long NameFault Injection

Interface0




NAOpenModel
Version that you started from. NOT the version you hope to release. If this will be v1.0.0, enter NA. Starting Baseline2.1.0, intending to baseline changes as 2.2.0EffortDesign0






FMEA
AuthorKevin DerryReview Effort(Hrs.)
Standards1






*.m File


Corr+Verf effort(Hrs.)
Documentation0






Cal Process


Total Effort (Hrs.)0.00Others0













Total1







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: 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?No

StandardsDesign is hybrid of EA4/EA3, per direction from s/w group. 100 errors in VerifyDD report.









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













Are all runnables defined?Yes













Do runnables have the correct time step?Yes













Do server runnables correctly define arguments?Yes













Are all clients defined?Yes













Do client definitions match the corresponding server runnable?Yes













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













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













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













Are all data types represented by released Data_Management classes?Yes













Do all calibrations have correct values for all metadata?Yes













Is NVM defined in the appropriate number of blocks?NA













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













Are all dependent constants and calibrations included in one file?NA













Does FDD.DesignASIL match requirements?NA




























2Section 2: ModelAuthor: 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








Is filename of model in correct format?Yes













Is Top level of model annotated with Requirements Baseline?Yes













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













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













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













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













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













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













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













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













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













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













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













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













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













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




























3Section 3: Requirements LinkingAuthor: 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








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













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













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













Is the list of unlinked blocks acceptable?NA




























4Section 4: Model AdvisorAuthor: 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








Was Model Advisor run with the correct configuration settings?Yes













Is the Model Advisor rerport free from "Fails".Yes













Are Model Advisor report "Warnings" acceptable?Yes




























5Section 5: Delivery PackageAuthor: 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








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?Yes













Was webview model created without requirements highlighted?Yes













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




























4Section 6: Other Issus/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














4.16














4.17














4.18














4.19














4.20














4.21














4.22














4.23














4.24














4.25














5Section 7: APPROVALS













RoleFirst ReviewDateAttendanceApproval?










Function Owner*Scott Millsap6/13/2016Yes
* The peer review consisted of Kevin in a conference room, Scott on the phone, and Gerald absent. It was agreed that Kevin would go to Synergy and examine ES209A to ensure that the new constant in DF001A matched the actual signal name in ES209A. It didn't, so the new DF001A constant was renamed from FLTINJ_CURRMEASCORRLN_MOTCURRIDPTSIG to FLTINJ_CURRMEASCORRLN_CURRMEASIDPTSIG. Dictionary, model change log, and reports were regenerated. No follow-up meeting. Design wass due yesterday for T1xx IVER build 6.0.







Peer Reviewer*Kevin Derry *Yes








SafetyScott Millsap









Software<Name - if invited>









ESG / SystemsGerald McCann









EPDT / CSE<Name - if invited>









Hardware<Name - if invited>









Test<Name - if invited>









RoleSecond Review (if required)DateAttendanceApproval?










Function Owner*<Owner Name>













Peer Reviewer*<Name>












Safety<Name - if invited>












Software<Name - if invited>












ESG / Systems<Name - if invited>












EPDT / CSE<Name - if invited>












Hardware<Name - if invited>












Test<Name - if invited>












RoleThird Review (if required)DateAttendanceApproval?










Function Owner*<Owner Name>













Peer Reviewer*<Name>












Safety<Name - if invited>












Software<Name - if invited>












ESG / Systems<Name - if invited>












EPDT / CSE<Name - if invited>












Hardware<Name - if invited>












Test<Name - if invited>












RoleFourth Review (if required)DateAttendanceApproval?










Function Owner*<Owner Name>













Peer Reviewer*<Name>












Safety<Name - if invited>












Software<Name - if invited>












ESG / Systems<Name - if invited>












EPDT / CSE<Name - if invited>












Hardware<Name - if invited>












Test<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
02.00.00Combined ESG and Systems into one, compatible with Data_Management 2.13.0 of CreateDD and VerifyDD.K. Derry
02.01.00Added: Does FDD.DesignASIL match requirements?
Added: Was webview model created without requirements highlighted?
Removed: Redundant row in Data Dictionary section.
Formatting: Column C now consistently center-justified.		K. Derry
02.02.00Added: Are all data types represented by released Data_Management classes?
Removed: Are all runnables defined? Rationale: Automated tools checking.
Removed: Does the Component shortname match data dictionary FDD metadata?
Removed: "Data store name must resolve to Simulink signal object"
Edited: Model Advisor report should now be left unzipped.		K. Derry











































































1.2 - DF001A_FltInj_ModelAdvisor

Model Advisor Report for 'DF001A_FltInj'
Model Advisor Report - DF001A_FltInj.slx
Simulink version: 8.2Model version: 1.401
System: DF001A_FltInjCurrent run: 10-Jun-2016 21:30:25
 Model Advisor configuration: ...NxtrModelAdvisorConfig.mat

Run Summary
PassFailWarningNot RunTotal
   51   0   16   292359


Model Advisor

    By Product

        Simulink

        Simulink Coder

        Embedded Coder

        Simscape

        Simulink Verification and Validation

            Modeling Standards

                DO-178C/DO-331 Checks

                IEC 61508, ISO 26262, and EN 50128 Checks

                MathWorks Automotive Advisory Board Checks

            Requirements Consistency

        Simulink Control Design

    By Task

        Code Generation Efficiency

 Check optimization settings

You should turn on the following optimization(s):

  • Block reduction
  • Remove code from floating-point to integer conversions that wraps out-of-range values
  • Inline invariant signals
  • The Simulation range checking diagnostic is enabled. Because this diagnostic can increase the time it takes to simulate your model, you should consider turning it off, by setting its value to none.
  • Ignore testpoints when generating code
  • Pass reusable subsystem outputs as individual arguments



    •         Frequency Response Estimation

            Managing Data Store Memory Blocks

            Managing Library Links And Variants

            Model Referencing

            Modeling Guidelines for MISRA-C:2004

            Modeling Physical Systems

            Modeling Signals and Parameters using Buses

            Modeling Single-Precision Systems

            Modeling Standards for DO-178C/DO-331

            Modeling Standards for EN 50128

            Modeling Standards for IEC 61508

            Modeling Standards for ISO 26262

     Display model metrics and complexity report

    Display number of elements and name, level, and depth of subsystems for the model or subsystem

    Model metrics information
    Display number of elements for Simulink blocks and Stateflow constructs


    Summary

    Element TypeCount
    Inport79
    Outport31
    SubSystem35


    Simulink

    Block TypeCount
    Inport79
    SubSystem35
    Outport31
    Terminator15
    S-Function6
    TriggerPort6
    Ground6
    EnablePort5
    DataStoreMemory5
    From4
    DataStoreWrite2
    Goto2
    BusCreator1
    Clock1
    ∧ Less

    Model complexity information
    Display name, level, and depth of subsystems


    Maximum Subsystem Depth: 6

    Subsystem Depth

    Subsystem NameLevelDepth
    CopyRight211
    Enabled Subsystem11
    Enabled Subsystem111
    Enabled Subsystem211
    Enabled Subsystem311
    Enabled Subsystem411
    FltInj15
    FltInj/CopyRight221
    FltInj/FltInjPer124
    FltInj/FltInjPer1/CopyRight231
    FltInj/FltInjPer1/Per1 Logic33
    FltInj/FltInjPer1/Per1 Logic/ProductionBuild42
    FltInj/FltInjPer1/Per1 Logic/ProductionBuild/CopyRight251
    FltInj/FltInj_f3224
    FltInj/FltInj_f32/ FltInj_f32 Logic33
    FltInj/FltInj_f32/ FltInj_f32 Logic/ProductionBuild42
    FltInj/FltInj_f32/ FltInj_f32 Logic/ProductionBuild/CopyRight251
    FltInj/FltInj_f32/CopyRight231
    FltInj/FltInj_logl24
    FltInj/FltInj_logl/CopyRight231
    FltInj/FltInj_logl/FltInj_lgc Logic33
    FltInj/FltInj_logl/FltInj_lgc Logic/ProductionBuild42
    FltInj/FltInj_logl/FltInj_lgc Logic/ProductionBuild/CopyRight251
    FltInj/FltInj_u0824
    FltInj/FltInj_u08/ FltInj_u08 Logic33
    FltInj/FltInj_u08/ FltInj_u08 Logic/ProductionBuild42
    FltInj/FltInj_u08/ FltInj_u08 Logic/ProductionBuild/CopyRight251
    FltInj/FltInj_u08/CopyRight231
    FltInj/FltInj_u0p1624
    FltInj/FltInj_u0p16/ FltInj_u0p16 Logic33
    FltInj/FltInj_u0p16/ FltInj_u0p16 Logic/ProductionBuild42
    FltInj/FltInj_u0p16/ FltInj_u0p16 Logic/ProductionBuild/CopyRight251
    FltInj/FltInj_u0p16/CopyRight231
    FltInj/UpdUsrPrm22
    FltInj/UpdUsrPrm/CopyRight231
    ∧ Less


     Check for root Inports with missing properties

    Identify Inport blocks in the top-level of the model with missing or inherited sample times, data types, or port dimensions

    Warning
    The following Inport blocks have undefined or inherited sample times, data types or port dimensions

    InportLinkConditions
    1DF001A_FltInj/In1Missing port dimension
    Missing signal data type
    Missing port sample time
    2DF001A_FltInj/In2Missing port dimension
    Missing signal data type
    Missing port sample time
    3DF001A_FltInj/In3Missing port dimension
    Missing signal data type
    Missing port sample time
    4DF001A_FltInj/In4Missing port dimension
    Missing signal data type
    Missing port sample time
    5DF001A_FltInj/In5Missing port dimension
    Missing signal data type
    Missing port sample time
    6DF001A_FltInj/In6Missing port dimension
    Missing signal data type
    Missing port sample time
    7DF001A_FltInj/trigger1Missing port dimension
    Missing signal data type
    Missing port sample time
    8DF001A_FltInj/trigger2Missing port dimension
    Missing signal data type
    Missing port sample time
    9DF001A_FltInj/trigger3Missing port dimension
    Missing signal data type
    Missing port sample time
    10DF001A_FltInj/trigger4Missing port dimension
    Missing signal data type
    Missing port sample time
    11DF001A_FltInj/trigger5Missing port dimension
    Missing signal data type
    Missing port sample time
    12DF001A_FltInj/In7Missing port dimension
    Missing signal data type
    Missing port sample time
    13DF001A_FltInj/In8Missing port dimension
    Missing signal data type
    Missing port sample time
    14DF001A_FltInj/In9Missing port dimension
    Missing signal data type
    Missing port sample time
    15DF001A_FltInj/In10Missing port dimension
    Missing signal data type
    Missing port sample time
    16DF001A_FltInj/In11Missing port dimension
    Missing signal data type
    Missing port sample time
    17DF001A_FltInj/In12Missing port dimension
    Missing signal data type
    Missing port sample time
    18DF001A_FltInj/In13Missing port dimension
    Missing signal data type
    Missing port sample time
    19DF001A_FltInj/In14Missing port dimension
    Missing signal data type
    Missing port sample time
    20DF001A_FltInj/In15Missing port dimension
    Missing signal data type
    Missing port sample time
    ∧ Less


    Recommended Action
    Explicitly define all missing Inport block properties identified in the results
    • Missing port dimension: Model contains Inport blocks with inherited port dimension (-1). Specify port dimension for the listed Inport blocks.
    • Missing signal data type: Model contains Inport blocks with inherited data type. Specify a data type for the listed Inport blocks.
    • Missing port sample time: Model contains Inport blocks with inherited sample time (-1). Specify sample time information for the listed Inport blocks. Note: The sample time of root Inports with bus type must match the sample times specified at the leaf elements of the bus object.

     Check for model objects that do not link to requirements

    Check Simulink blocks and Stateflow objects that do not link to a requirements document

    Warning
    The following blocks do not link to a requirement document:

    ∧ Less
    Recommended Action
    For each object in the list, in the Model Editor, right-click the block, select Requirements, and specify a requirement.



            Modeling Standards for MAAB

                Naming Conventions

     Check folder names

    Identify folders using incorrect characters and formatting.

    See Also

    Warning
    The following folders have incorrect names:

    FolderIncorrect Character or Format
    C:/Users/lzz0tm/Google Drive/Software Components/DF001A Fault Injection/EA4/DF001A_FltInj_Design_2.2.0/DesignFolder name includes incorrect characters or formatting.


    Recommended Action
    Rename the above folders to remove incorrect characters and formatting.

     Check subsystem names

    Identify subsystem names that use characters that are not correct in C code.

    See Also

    Warning
    The following subsystem names contain incorrect characters:

    ErrorSubsystem block
    Name contains incorrect characters.DF001A_FltInj/Enabled Subsystem
    Name contains incorrect characters.DF001A_FltInj/Enabled Subsystem1
    Name contains incorrect characters.DF001A_FltInj/Enabled Subsystem2
    Name contains incorrect characters.DF001A_FltInj/Enabled Subsystem3
    Name contains incorrect characters.DF001A_FltInj/Enabled Subsystem4


    Recommended Action
    Rename the subsystem blocks using correct characters.

     Check character usage in block names

    Identify block names that use characters that are not correct in C code.

    See Also

    Warning
    The following block names use characters that are not correct for C code:

    Error typeBlock
    Name contains incorrect characters...../Enabled Subsystem/Function-Call
    Name contains incorrect characters...../Enabled Subsystem1/Function-Call
    Name contains incorrect characters...../Enabled Subsystem2/Function-Call
    Name contains incorrect characters...../Enabled Subsystem3/Function-Call
    Name contains incorrect characters...../Enabled Subsystem4/Function-Call


    Recommended Action
    Rename the block using correct characters.



                Model Architecture

                Model Configuration Options

                Simulink

     Check for Simulink diagrams using nonstandard display attributes

    Identify nonstandard display attributes in Simulink diagrams.

    See Also

    _________________________________________________________________________________________

    Check format settings
    Identify incorrect model-level format options.

    Warning
    The following format display options are incorrect.

    Display AttributeRecommended ValueActual Value
    Display > Signals & Ports > Wide Nonscalar Linesonoff
    Status bar is not visible.onoff
    View > Model Browser Options > Model Browseroffon
    Display > Library Links > Allnonedisabled


    Recommended Action
    Set the format options to the recommended value.
    _________________________________________________________________________________________

    Check block colors
    Identify blocks using nonstandard colors.

    Warning
    The following blocks use nonstandard colors:

    Recommended Action
    Set the block foreground color to black and the background color to white.
    _________________________________________________________________________________________

    Check canvas colors
    Identify canvases that are not white.

    Passed
    All diagrams use a white canvas.
    _________________________________________________________________________________________

    Check diagram zoom
    Identify diagrams that do not have zoom factor set to 100 %.

    Warning
    The following diagrams do not have zoom factor set to 100 percent:

    ∧ Less
    Recommended Action
    For each listed diagram, select View > Zoom > Normal View (100%).

     Check font formatting

    Identify inconsistent formatting of text.

    See Also

    Warning
    Font formatting is not consistent.

    The following font characteristics are used in the model/subsystem. Font characteristics are sorted by number of occurrences. The most common characteristics are bold.
    Font NameFont SizeFont Style

    Helvetica
    Arial

    10
    14
    9

    normal



    Recommended Action
    To have consistent font formatting, click Modify All Fonts to apply the font formatting selected in the input parameters above to all objects.

    Input Parameters Selection
    NameValue
    Font NameCommon
    Font SizeCommon
    Font StyleCommon

     Check positioning and configuration of ports

    Identify input and output ports with incorrect positioning and configurations.

    See Also

    _________________________________________________________________________________________

    Check Inport blocks position
    Identify Inport blocks that result in left-flowing signals.

    Passed
    There are no Inport blocks in the model that result in left-flowing signals.
    _________________________________________________________________________________________

    Check Outport block position
    Identify Outport blocks that result in left-flowing signals.

    Passed
    There are no Outport blocks in the model that result in left-flowing signals.
    _________________________________________________________________________________________

    Check port orientation
    Identify port blocks with nondefault orientation.

    Passed
    All ports use the default orientation.
    _________________________________________________________________________________________

    Check for duplicate Inports blocks
    Identify duplicate Inport blocks.

    Passed
    All Inport blocks in the model are used once.

     Check visibility of block port names

    Identify port block names that are not uniformly displayed. The block names must all be displayed or none displayed. Library blocks are an exception to this rule. This check ignores masked and subsystem blocks.

    See Also

    _________________________________________________________________________________________

    Check for incorrect port name display
    Identify ports that are incorrectly displaying names.

    Passed
    Subsystem blocks are correctly displayed.
    _________________________________________________________________________________________

    Check for incorrect subsystem port name display
    Identify subsystems that are incorrectly displaying names.

    Passed
    Subsystem blocks are correctly displayed.

    Input Parameters Selection
    NameValue
    Display all port names (Diagram > Format > Show Block Name).true

     Check the display attributes of block names

    Identify whether to display block names.

    See Also

    _________________________________________________________________________________________

    Check for blocks with hidden names and obvious function
    Identify block names that are displayed but can be hidden due to obvious behavior.

    Warning
    The following block names can be hidden:

    Recommended Action
    Hide the block name by deselecting (Diagram > Format > Show Block Name).
    _________________________________________________________________________________________

    Check for non-descriptive displayed block names
    Identify block names that are displayed but should be hidden due to a lack of a descriptive name.

    Warning
    The following blocks have a name displayed, however, the name is not descriptive:

    Recommended Action
    Modify the block name to provide descriptive information, or hide the block name by deselecting (Diagram > Format > Show Block Name).
    _________________________________________________________________________________________

    Check for missing block names
    Identify block names that are hidden but should be displayed to show a descriptive name.

    Warning
    The following blocks have descriptive names, however, the names are hidden:

    Recommended Action
    Modify the blocks to show the block name (Diagram > Format > Show Block Name).

     Check position of Trigger and Enable blocks

    Identify Trigger and Enable blocks that are not centered in the upper third of the model diagram.

    See Also

    Warning
    The following Trigger and Enable blocks are not centered in the upper third of the model diagram:Recommended Action
    Move the above Trigger or Enable blocks such that it is centered in the upper third of the model diagram.

     Check signal line labels

    Identify blocks that require labeled signals. A subset of source and destination blocks require labeled signals.

    See Also

    _________________________________________________________________________________________

    Check source block labels
    The following source blocks require labeled signals; Inport, From, Data Store Read, Constant, Bus Selector, Demux, Selector. If the signal name is visible on the block, this rule is considered met.

    Warning
    The following signals have no label:

    ∧ Less
    Recommended Action
    Add a new or propagated label to the signal line.
    _________________________________________________________________________________________

    Check destination block labels
    The following destination blocks require labeled signals; Outport, Goto, Data Store Write, Bus Creator, Mux, Subsystem, Chart. If the signal name is visible on the source block, this rule is considered met.

    Warning
    The following signals have no label:

    ∧ Less
    Recommended Action
    Add a new or propagated label to the signal line.

     Check for propagated signal labels

    Identify propagated labels on signal lines.

    See Also

    _________________________________________________________________________________________

    Check subsystem input labels
    Identify subsystem inputs that are labeled and display propagated signals.

    Passed
    All inputs to the subsystem have labels and display propagated signals.
    _________________________________________________________________________________________

    Check subsystem output labels
    Identify outputs from subsystems that are labeled and display signal propagation.

    Passed
    All outputs from the subsystem have labels and display propagated signals.
    _________________________________________________________________________________________

    Signal propagation for nonsubsystem blocks
    Identify the signal propagation status for both transformative and nontransformative blocks.

    Passed
    All outputs from non subsystem blocks correctly use labels and display propagated signals.



                Stateflow

     Check usage of exclusive and default states in state machines

    Identify Stateflow charts and substates that incorrectly use or define exclusive and default states.
    Note: This check does not support charts that use MATLAB as the action language.

    See Also

    _________________________________________________________________________________________

    Check Stateflow charts for exclusive states
    Identify Stateflow charts that have singular exclusive (OR) states.

    Passed
    The Stateflow charts do not have singular exclusive (OR) states.
    _________________________________________________________________________________________

    Check Stateflow charts for undefined default states
    Identify Stateflow charts that do not define default states.

    Passed
    Each Stateflow chart defines a default state.
    _________________________________________________________________________________________

    Check for multiple states assigned as the default state
    At the root level in the Stateflow hierarchy only one state should be assigned as the default.

    Passed
    The root level of the chart has only one default state assigned.
    _________________________________________________________________________________________

    Check for substates with singular OR states
    States configured as OR should always be part of a group of states.

    Passed
    No singular OR states were detected.
    _________________________________________________________________________________________

    Check for substates without default states defined
    At every level in the Stateflow hierarchy a default state should be assigned.

    Passed
    All substates have default states assigned.
    _________________________________________________________________________________________

    Check for substates with multiple default states defined
    At every level in the Stateflow hierarchy only one state should be assigned as the default.

    Passed
    All levels of the chart have only one default state assigned.

     Check transition orientations in flowcharts

    Identify transitions in Stateflow flowcharts that are drawn incorrectly.

    See Also

    _________________________________________________________________________________________

    Check for conditions drawn vertically
    Condition expressions should be drawn on the horizontal segments of flowcharts.

    Passed
    All conditions expressions were drawn horizontally.
    _________________________________________________________________________________________

    Check for action transitions drawn vertically
    Transition actions should be drawn on the vertical segments of flowcharts.

    Passed
    All transitions actions where drawn vertically.
    _________________________________________________________________________________________

    Check for junctions for default transitions
    All Junctions in a flow chart should have a default exit transition.

    Passed
    All Junctions have a default exit transition.
    _________________________________________________________________________________________

    Check for transitions that combine condition and action
    Flowcharts should not combine condition evaluations and action expressions in a single transition.

    Passed
    No combined expressions where found in the chart.



                MATLAB Functions

            Requirements Consistency Checking

            Simulation Accuracy

            Simulation Runtime Accuracy Diagnostics

     Check if Read/Write diagnostics are enabled for Data Store blocks

    Note: These runtime diagnostics may slow down simulation considerably. You should set them back to Disable all once you have verified that they do not cause any warnings or errors during simulation.



            Simulink Model File Integrity

            Upgrading to the Current Simulink Version

    2 - Component Design

    Component Design

    Component Documentation

    2.1 - DF002A_Swp_PeerReview

    Changes based on software group Peer Review (Selva, Anne, Creager):

    1) Outputs are not range limited. -Modifications done to add saturation on outputs of sweep.

    2) Req Tags and legacy comments are to be removed from the model - Done

    3) SWPTIUNITCNVN shall be used instead of 1/10 -Done

    3 - Component Implementation

    Component Implementation

    Component Documentation

    3.1 - FltInj_IntegrationManual

    Integration Manual

    For

    FltInj

    VERSION: 1.0

    DATE: 08/25/15

    Prepared By:

    Software Group,

    Nexteer Automotive,

    Saginaw, MI, USA

    Location: The official version of this document is stored in the Nexteer Configuration Management System.

    Revision History

    DescriptionAuthorVersionDate
    Initial versionLucas Wendling1.008/25/15

    Table of Contents

    1 Abbrevations And Acronyms 4

    2 References 5

    3 Dependencies 6

    3.1 SWCs 6

    3.2 Global Functions(Non RTE) to be provided to Integration Project 6

    4 Configuration REQUIREMeNTS 7

    4.1 Build Time Config 7

    4.2 Configuration Files to be provided by Integration Project 7

    4.3 Da Vinci Parameter Configuration Changes 7

    4.4 DaVinci Interrupt Configuration Changes 7

    4.5 Manual Configuration Changes 7

    5 Integration DATAFLOW REQUIREMENTS 8

    5.1 Required Global Data Inputs 8

    5.2 Required Global Data Outputs 8

    5.3 Specific Include Path present 8

    6 Runnable Scheduling 9

    7 Memory Map REQUIREMENTS 10

    7.1 Mapping 10

    7.2 Usage 10

    7.3 NvM Blocks 10

    8 Compiler Settings 11

    8.1 Preprocessor MACRO 11

    8.2 Optimization Settings 11

    9 Appendix 12

    Abbrevations And Acronyms

    AbbreviationDescription
    DFDDesign functional diagram
    MDDModule design Document
    <ADD more to the table if applicable>

    References

    This section lists the title & version of all the documents that are referred for development of this document

    Sr. No.TitleVersion
    1EA4 Software Naming Conventions.doc01.00.00
    2Software Design and Coding Standards.doc2.1
    3DF001A_FltInj_DesignSee Synergy subproject version

    Dependencies

    SWCs

    ModuleRequired Feature
    None

    Note : Referencing the external components should be avoided in most cases. Only in unavoidable circumstance external components should be referred. Developer should track the references.

    Global Functions(Non RTE) to be provided to Integration Project

    None

    Configuration REQUIREMeNTS

    Build Time Config

    Build Constant NameNotes
    FLTINJENASet to STD_ON for fault injection software build, set to STD_OFF for normal build. Constant resides in “FltInj.h” file.

    Configuration Files to be provided by Integration Project

    None

    Da Vinci Parameter Configuration Changes

    ParameterNotesSWC
    None

    DaVinci Interrupt Configuration Changes

    ISR NameVIM #Priority DependencyNotes
    None

    Manual Configuration Changes

    ConstantNotesSWC
    None

    Integration DATAFLOW REQUIREMENTS

    Required Global Data Inputs

    See DataDict.m file

    Required Global Data Outputs

    See DataDict.m file

    Specific Include Path present

    Yes

    Runnable Scheduling

    This section specifies the required runnable scheduling.

    InitScheduling RequirementsTrigger
    None
    RunnableScheduling RequirementsTrigger
    FltInjPer1NoneRTE 2ms
    FltInj_f32_OperNoneOn Invocation
    FltInj_logl_OperNoneOn Invocation
    FltInj_u08_OperNoneOn Invocation
    FltInj_u0p16_OperNoneOn Invocation

    .

    Memory Map REQUIREMENTS

    Mapping

    Memory SectionContentsNotes
    FltInj_START_SEC_CODEFault Injection code and variablesThis code section statement will contain variables that need mapping to GlobalShared memory during fault injection builds (these variables are present when FLTINJENA == STD_ON)

    * Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.

    Usage

    FeatureRAMROM

    Table 1: ARM Cortex R4 Memory Usage

    NvM Blocks

    None

    Compiler Settings

    Preprocessor MACRO

    None

    Optimization Settings

    None

    Appendix

    <This section is for appendix>

    3.2 - FltInj_MDD

    Module Design Document

    For

    FltInj

    04/29/2016

    Prepared For:

    Software Engineering

    Nexteer Automotive,

    Saginaw, MI, USA

    Prepared By:

    Krishna Anne,

    Nexteer Automotive,

    Saginaw, MI, USA
    Change History

    DescriptionAuthorVersionDate
    Initial VersionLucas Wendling1.008/26/15
    Updates are per FDD v2.1.0Krishna Anne2.004/29/16


    Table of Contents

    1 Introduction 5

    1.1 Purpose 5

    1.2 Scope 5

    2 <Component Name> & High-Level Description 6

    3 Design details of software module 7

    3.1 Graphical representation of <Component Name> 7

    3.2 Data Flow Diagram 7

    3.2.1 Component level DFD 7

    3.2.2 Function level DFD 7

    4 Constant Data Dictionary 8

    4.1 Program (fixed) Constants 8

    4.1.1 Embedded Constants 8

    5 Software Component Implementation 9

    5.1 Sub-Module Functions 9

    5.1.1 Init: <Component Name>_Init<n> 9

    5.1.1.1 Design Rationale 9

    5.1.1.2 Module Outputs 9

    5.1.2 Per: <Component Name>_Per<n> 9

    5.1.2.1 Design Rationale 9

    5.1.2.2 Store Module Inputs to Local copies 9

    5.1.2.3 (Processing of function)……… 9

    5.1.2.4 Store Local copy of outputs into Module Outputs 9

    5.2 Server Runables 9

    5.2.1 <Server Runable Name> 9

    5.2.1.1 Design Rationale 9

    5.2.1.2 (Processing of function)……… 10

    5.3 Interrupt Functions 10

    5.3.1 Interrupt Function Name 10

    5.3.1.1 Design Rationale 10

    5.3.1.2 (Processing of the ISR function)….. 10

    5.4 Module Internal (Local) Functions 10

    5.4.1 Local Function #1 10

    5.4.1.1 Design Rationale 10

    5.4.1.2 Processing 10

    5.5 GLOBAL Function/Macro Definitions 10

    5.5.1 GLOBAL Function #1 10

    5.5.1.1 Design Rationale 11

    5.5.1.2 processing 11

    6 Known Limitations with Design 12

    7 UNIT TEST CONSIDERATION 13

    Appendix A Abbreviations and Acronyms 14

    Appendix B Glossary 15

    Appendix C References 16

    Introduction

    Purpose

    MDD for FltInj (DF001A).

    FltInj High-Level Description

    Refer FDD

    Design details of software module

    Graphical representation of FltInj

    Data Flow Diagram

    Component level DFD

    Function level DFD

    Constant Data Dictionary

    Program (fixed) Constants

    Embedded Constants

    Local Constants

    Constant NameResolutionUnitsValue
    TICNVN_MICROTOMILLI_F32Single precision floatMicroToMilli0.001

    • For other constants, refer DataDict.m

    Software Component Implementation

    Sub-Module Functions

    Init:

    None

    Design Rationale

    N/A

    Module Outputs

    N/A

    Per: FltInjPer1

    Design Rationale

    Refer FDD

    Store Module Inputs to Local copies

    Refer FDD

    (Processing of function)………

    Refer FDD

    Store Local copy of outputs into Module Outputs

    Refer FDD

    Server Runables

    FltInj_f32_Oper

    Design Rationale

    Refer FDD

    (Processing of function)………

    Refer FDD

    FltInj_logl_Oper

    Design Rationale

    Refer FDD

    (Processing of function)………

    Refer FDD

    FltInj_u08_Oper

    Design Rationale

    Refer FDD

    (Processing of function)………

    Refer FDD

    FltInj_u0p16_Oper

    Design Rationale

    Refer FDD

    (Processing of function)………

    Refer FDD

    Interrupt Functions

    None

    Interrupt Function Name

    N/A

    Design Rationale

    N/A

    (Processing of the ISR function)…..

    N/A

    Module Internal (Local) Functions

    NA

    GLOBAL Function/Macro Definitions

    NA

    Known Limitations with Design

    UNIT TEST CONSIDERATION

    1. Unit testing should be performed for when the build constant FLTINJENA is set to STD_ON in order to enable core functionality of this module. This will have to be done by manually altering FltInj.h to change the value of this #define.

    2. The SigPah_Arg signal of the FltInj_f32 server runnable has a special unit test consideration (MIL, SIL, PIL) that the range called out in the data dictionary should only be used for defining "input" vectors, and the range check that is normal done on the "output" is skipped in this special instance. (This second point is copied from the FDD).

    Abbreviations and Acronyms

    Abbreviation or AcronymDescription

    Glossary

    Note: Terms and definitions from the source “Nexteer Automotive” take precedence over all other definitions of the same term. Terms and definitions from the source “Nexteer Automotive” are formulated from multiple sources, including the following:

    • ISO 9000

    • ISO/IEC 12207

    • ISO/IEC 15504

    • Automotive SPICE® Process Reference Model (PRM)

    • Automotive SPICE® Process Assessment Model (PAM)

    • ISO/IEC 15288

    • ISO 26262

    • IEEE Standards

    • SWEBOK

    • PMBOK

    • Existing Nexteer Automotive documentation

    TermDefinitionSource
    MDDModule Design Document
    DFDData Flow Diagram

    References

    Ref. #TitleVersion
    1AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)v1.3.0 R4.0 Rev 2
    2MDD GuidelineEA4 01.00.00
    3EA4 Software Naming Conventions.doc01.00.00
    4Software Design and Coding Standards.doc2.1
    4DF001A_FltInj_DesignSee Synergy subproject version

    3.3 - FltInj_PeerReview

    Overview

    Summary Sheet
    Synergy Project
    Source Code
    PolySpace

    Sheet 1: Summary Sheet
























    		Rev 1.28-Jun-15

    		Peer Review Summary Sheet


























    		Synergy Project Name:


    		kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. DF001A_FltInj_Impl
    		Revision / Baseline:


    		kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. DF001A_FltInj_Impl_1.4.0

























    Change Owner:


    		kzshz2: Intended Use: Identify the developer who made the change(s) Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards. Krishna Anne
    		Work CR ID:


    		EA4#7009





























    		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


    		YesSource Code


    		YesPolySpace









































    		Integration Manual


    		Davinci Files








































































    		Comments:

    		Reviewd changes alone



























































































    		General Guidelines:
    - The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
    - New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
    - Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
    - To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
    - .h file should be reviewed with the source file as part of the source file.




















    Sheet 2: Synergy Project

    Peer Review Meeting Log (Component Synergy Project Review)



















































    		Quality Check Items:




































    		Rationale is required for all answers of No










    		New baseline version name from Summary Sheet follows








    		Yes
    		Comments:



    naming convention





































    Project contains necessary subprojects








    		Yes
    		Comments:










































    Project contains the correct version of subprojects








    		Yes
    		Comments:










































    Design subproject is correct version








    		Yes
    		Comments:











































    		General Notes / Comments:



























































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Krishna Anne


    		Review Date :

    		09/09/16
































    		Lead Peer Reviewer:


    		Nick Saxton


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    Sheet 3: Source Code






















    		Rev 1.28-Jun-15
    Peer Review Meeting Log (Source Code Review)

























    Source File Name:


    		FltInj.c

    		Source File Revision:


    		2
    Header File Name:


    		FltInj.h

    		Header 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. 4

























    MDD Name:

    		FltInj_MDD

    		Revision:
    		2

























    FDD/SCIR/DSR/FDR/CM Name:




    		DF001A_FltInj_Design

    		Revision:
    		2.2.0


























    		Quality Check Items:



































    		Rationale is required for all answers of No









    Working EA4 Software Naming Convention followed:















































    		for variable names







    		N/A
    		Comments:

















































    		for constant names







    		Yes
    		Comments:

















































    		for function names







    		N/A
    		Comments:

















































    		for other names (component, memory







    		N/A
    		Comments:










    		mapping handles, typedefs, etc.)




































    All paths assign a value to outputs, ensuring








    		N/A
    		Comments:









    all outputs are initialized prior to being written





































    Requirements Tracability tags in code match the requirements tracability in the FDD








    		N/A
    		Comments:









    requirements tracability in the FDD





































    All variables are declared at the function level.








    		N/A
    		Comments:
























    Synergy version matches change history





    		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.


    		Yes
    		Comments:



    and Version Control version in file comment block





































    Change log contains detailed description of changes








    		Yes
    		Comments:



    and Work CR number





































    Code accurately implements FDD (Document or Model)








    		Yes
    		Comments:










































    Verified no Compiler Errors or Warnings


    		KMC: Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored). Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project should be used; QAC can find compiler errors but not warnings.





    		Yes
    		Comments:
















































    Component.h is included








    		Yes
    		Comments:
























    All other includes are actually needed. (System includes








    		N/A
    		Comments:









    only allowed in Nexteer library components)





































    Software Design and Coding Standards followed:











    		Version: 2.1

























    		Code comments are clear, correct, and adequate







    		Yes
    		Comments:










    		and have been updated for the change: [N40] and













    		all other rules in the same section as rule [N40],






















    		plus [N75], [N12], [N23], [N33], [N37], [N38],






















    		[N48], [N54], [N77], [N79], [N72]














































    		Source file (.c and .h) comment blocks are per







    		Yes
    		Comments:










    		standards and contain correct information: [N41], [N42]





































    		Function comment blocks are per standards and







    		N/A
    		Comments:










    		contain correct information: [N43]





































    		Code formatting (indentation, placement of







    		Yes
    		Comments:










    		braces, etc.) is per standards: [N5], [N55], [N56],













    		[N57], [N58], [N59]














































    		Embedded constants used per standards; no







    		Yes
    		Comments:










    		"magic numbers": [N12]





































    		Memory mapping for non-RTE code







    		N/A
    		Comments:










    		is per standard





































    		All execution-order-dependent code can be







    		N/A
    		Comments:










    		recognized by the compiler: [N80]





































    		All loops have termination conditions that ensure







    		N/A
    		Comments:










    		finite loop iterations: [N63]





































    		All divides protect against divide by zero







    		N/A
    		Comments:










    		if needed: [N65]





































    		All integer division and modulus operations







    		N/A
    		Comments:










    		handle negative numbers correctly: [N76]





































    		All typecasting and fixed point arithmetic,







    		N/A
    		Comments:










    		including all use of fixed point macros and













    		timer functions, is correct and has no possibility






















    		of unintended overflow or underflow: [N66]














































    		All float-to-unsiged conversions ensure the.







    		N/A
    		Comments:










    		float value is non-negative: [N67]





































    		All conversions between signed and unsigned







    		N/A
    		Comments:










    		types handle msb==1 as intended: [N78]





































    		All pointer dereferencing protects against







    		N/A
    		Comments:










    		null pointer if needed: [N70]





































    		Component outputs are limited to the legal range







    		N/A
    		Comments:










    		defined in the FDD DataDict.m file : [N53]





































    		All code is mapped with FDD (all FDD







    		Yes
    		Comments:










    		subfunctions and/or model blocks identified













    		with code comments; all code corresponds to






















    		some FDD subfunction and/or model block): [N40]













































    Review did not identify violations of other








    		Yes
    		Comments:









    coding standard rules





































    Anomaly or Design Work CR created








    		N/A
    		Comments: List Anomaly or CR numbers









    for any FDD corrections needed































































    		General Notes / Comments:

















































































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Krishna Anne


    		Review Date :

    		09/09/16
































    		Lead Peer Reviewer:


    		Nick Saxton


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    Sheet 4: PolySpace






















    		Rev 1.28-Jun-15
    Peer Review Meeting Log (QAC/PolySpace Review)


























    		Source File Name:


    		FltInj.c











    		Source File Revision:


    		2

    		Source File Name:


    		FltInj.h











    		Source File Revision:


    		4

    		Source File Name:















    		Source File Revision:






























    		EA4 Static Analysis Compliance Guideline version:







    		01.01.00














    		Poly Space version:


    		Windows User: eg. 2013b 2013b





    		Polyspace sub project version:




    		Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 TL108A_PolyspaceSuprt_1.0.0






    		QAC version:


    		Windows User: eg 8.1.1-R 8.1.1-R





    		QAC sub project version:




    		Windows User: eg. TL_100A_1.1.0 TL100A_QACSuprt_1.2.0































    		Quality Check Items:




































    		Rationale is required for all answers of No



































    		Contract Folder's header files are appropriate and





    		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.


    		Yes
    		Comments:




    		function prototypes match the latest component version







































    		100% Compliance to the EA4 Static AnalysisYes
    		Comments:





    		Compliance Guideline





























    		Are previously added justification and deviation








    		Yes
    		Comments:





    		comments still appropriate






































    		Do all MISRA deviation comments use approved








    		Yes
    		Comments:





    		deviation tags






































    		Cyclomatic complexity and Static path count OK






    		Creager, Kathleen: use Browse Function Metrics, STCYC and STPTH

    		Yes
    		Comments:





    		for all functions in the component per Design














    		and Coding Standards rule [N47]

































































































    		General Notes / Comments:



























































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Krishna Anne


    		Review Date :

    		09/09/16
































    		Lead Peer Reviewer:


    		Nick Saxton


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    4 - Component Implementation

    Component Implementation

    Component Documentation

    4.1 - McuErrInj_Design_Review

    Overview

    Summary Sheet
    Synergy Project
    Source Code

    Sheet 1: Summary Sheet
























    		Rev 1.28-Jun-15


    		Peer Review Summary Sheet





























    		Synergy Project Name:


    		kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. DF003A_McuErrInj_Impl
    		Revision / Baseline:


    		kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. 0.0.1




























    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. Avinash James
    		Work CR ID:


    		EA4#6934
































    		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:



































    		N/AMDD


    		YesSource Code


    		N/APolySpace













































    		N/AIntegration Manual


    		N/ADavinci Files














































































    		Comments:

    		Reviewed only the stub file. No MDD or integration manual






    		Dummy project for including error injection header definition



























































































    		General Guidelines:
    - The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
    - New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
    - Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
    - To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
    - .h file should be reviewed with the source file as part of the source file.









































    Sheet 2: Synergy Project

    Peer Review Meeting Log (Component Synergy Project Review)



















































    		Quality Check Items:




































    		Rationale is required for all answers of No










    		New baseline version name from Summary Sheet follows








    		Yes
    		Comments:



    naming convention





































    Project contains necessary subprojects








    		Yes
    		Comments:










































    Project contains the correct version of subprojects








    		Yes
    		Comments:










































    Design subproject is correct version








    		No
    		Comments:

    		Dummy project for including error injection header definition








































    		General Notes / Comments:



























































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Avinash James


    		Review Date :

    		12/13/16
































    		Lead Peer Reviewer:


    		Selva Sengottaiyan


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    Sheet 3: Source Code






















    		Rev 1.28-Jun-15
    Peer Review Meeting Log (Source Code Review)

























    Source File Name:





    		Source File Revision:



    Header File Name:


    		McuErrInj.h

    		Header 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

    		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

























    FDD/SCIR/DSR/FDR/CMS Revision:




    		nz63rn: Intended Use: Identify which version of which FDD/CMS/SER this source file was written against. Rationale: Needed for traceability between source code and FDD/CMS/SER


























    		Quality Check Items:



































    		Rationale is required for all answers of No









    Working EA4 Software Naming Convention followed:















































    		for variable names







    		Yes
    		Comments:

















































    		for constant names







    		Yes
    		Comments:

















































    		for function names







    		N/A
    		Comments:

















































    		for other names (component, memory







    		N/A
    		Comments:










    		mapping handles, typedefs, etc.)




































    All paths assign a value to outputs, ensuring








    		N/A
    		Comments:









    all outputs are initialized prior to being written





































    Requirements Tracability tags in code match the requirements tracability in the FDD








    		N/A
    		Comments:
    		No Tags in FDD currently







    requirements tracability in the FDD





































    All variables are declared at the function level.








    		N/A
    		Comments:
























    Synergy version matches change history





    		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.


    		Yes
    		Comments:



    and Version Control version in file comment block





































    Change log contains detailed description of changes








    		Yes
    		Comments:



    and Work CR number





































    Code accurately implements FDD (Document or Model)








    		Yes
    		Comments:










































    Verified no Compiler Errors or Warnings


    		KMC: Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored). Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project should be used; QAC can find compiler errors but not warnings.





    		Yes
    		Comments:
















































    Component.h is included








    		N/A
    		Comments:
























    All other includes are actually needed. (System includes








    		Yes
    		Comments:









    only allowed in Nexteer library components)





































    Software Design and Coding Standards followed:











    		Version:

























    		Code comments are clear, correct, and adequate







    		Yes
    		Comments:










    		and have been updated for the change: [N40] and













    		all other rules in the same section as rule [N40],






















    		plus [N75], [N12], [N23], [N33], [N37], [N38],






















    		[N48], [N54], [N77], [N79], [N72]














































    		Source file (.c and .h) comment blocks are per







    		Yes
    		Comments:










    		standards and contain correct information: [N41], [N42]





































    		Function comment blocks are per standards and







    		Yes
    		Comments:










    		contain correct information: [N43]





































    		Code formatting (indentation, placement of







    		Yes
    		Comments:










    		braces, etc.) is per standards: [N5], [N55], [N56],













    		[N57], [N58], [N59]














































    		Embedded constants used per standards; no







    		Yes
    		Comments:










    		"magic numbers": [N12]





































    		Memory mapping for non-RTE code







    		N/A
    		Comments:










    		is per standard





































    		All execution-order-dependent code can be







    		N/A
    		Comments:










    		recognized by the compiler: [N80]





































    		All loops have termination conditions that ensure







    		N/A
    		Comments:










    		finite loop iterations: [N63]





































    		All divides protect against divide by zero







    		N/A
    		Comments:










    		if needed: [N65]





































    		All integer division and modulus operations







    		N/A
    		Comments:










    		handle negative numbers correctly: [N76]





































    		All typecasting and fixed point arithmetic,







    		N/A
    		Comments:










    		including all use of fixed point macros and













    		timer functions, is correct and has no possibility






















    		of unintended overflow or underflow: [N66]














































    		All float-to-unsiged conversions ensure the.







    		N/A
    		Comments:










    		float value is non-negative: [N67]





































    		All conversions between signed and unsigned







    		N/A
    		Comments:










    		types handle msb==1 as intended: [N78]





































    		All pointer dereferencing protects against







    		N/A
    		Comments:










    		null pointer if needed: [N70]





































    		Component outputs are limited to the legal range







    		N/A
    		Comments:










    		defined in the FDD DataDict.m file : [N53]





































    		All code is mapped with FDD (all FDD







    		Yes
    		Comments:










    		subfunctions and/or model blocks identified













    		with code comments; all code corresponds to






















    		some FDD subfunction and/or model block): [N40]













































    Review did not identify violations of other








    		Yes
    		Comments:









    coding standard rules





































    Anomaly or Design Work CR created








    		N/A
    		Comments:









    for any FDD corrections needed































































    		General Notes / Comments:
















































    		Reviewed only the stub file. No MDD or integration manual































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Avinash James


    		Review Date :

    		12/13/16
































    		Lead Peer Reviewer:


    		Selva Sengottaiyan


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    5 - Component Implementation

    Component Implementation

    Component Documentation

    5.1 - Swp_DesignReview

    Overview

    Summary Sheet
    Synergy Project
    Davinci Files
    Source Code
    MDD
    PolySpace
    Integration Manual

    Sheet 1: Summary Sheet
























    		Rev 1.28-Jun-15

    		Peer Review Summary Sheet


























    		Synergy Project Name:


    		kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. DF002A_Swp_Impl
    		Revision / Baseline:


    		kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. DF002A_Swp_Impl_1.1.0

























    Change Owner:


    		kzshz2: Intended Use: Identify the developer who made the change(s) Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards. Krishna Anne
    		Work CR ID:


    		EA4#3356





























    		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:































    		YesMDD


    		YesSource Code


    		YesPolySpace









































    		YesIntegration Manual


    		YesDavinci Files








































































    		Comments:






























































































    		General Guidelines:
    - The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
    - New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
    - Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
    - To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
    - .h file should be reviewed with the source file as part of the source file.




















    Sheet 2: Synergy Project

    Peer Review Meeting Log (Component Synergy Project Review)



















































    		Quality Check Items:




































    		Rationale is required for all answers of No










    		New baseline version name from Summary Sheet follows








    		Yes
    		Comments:



    naming convention





































    Project contains necessary subprojects








    		Yes
    		Comments:










































    Project contains the correct version of subprojects








    		Yes
    		Comments:










































    Design subproject is correct version








    		Yes
    		Comments:











































    		General Notes / Comments:



























































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Krishna Anne


    		Review Date :

    		02/08/16
































    		Lead Peer Reviewer:


    		Kathleen Creager


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    Sheet 3: Davinci Files






















    		Rev 1.28-Jun-15
    Peer Review Meeting Log (Davinci Review)


























    		Quality Check Items:




































    		Rationale is required for all answers of No










    		Only StdDef Port types are used








    		Yes
    		Comments:










































    For components not using application data types, do all








    		Yes
    		Comments:



    port interface names end in PortIf and a sequence number





























































    Non-program-specific components saved








    		Yes
    		Comments:




    		in Autosar 4.0.3 format




































    *Cfg.arxml.TT: Verfied Davinci Configurator imported the








    		N/A
    		Comments:




    		change correctly




































    *Cfg.h.TT: Verfied Davinci Configurator generates








    		N/A
    		Comments:










    		the configuration header(s) file correctly
    		kzshz2: Either a generic sandbox or a baselined integration project can be used to verify



























    		kzshz2: Either a generic sandbox or a baselined integration project can be used to verify
















    All changed files have been compared against previous








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


































    Automated validation check is performed








    		Yes
    		Comments:

























































    Naming conventions followed. All names should








    		Yes
    		Comments:










    		match DataDict.m










    		Devations are there from regular EA4 standards

































    Sender/Receiver port properties match DataDict.m








    		Yes
    		Comments:










    		file (use .m file helper tool)













































    Calibration port properties match DataDict.m








    		N/A
    		Comments:










    		file (use .m file helper tool)













































    Components using application data types:























    		Sender/Receiver port initialization values match







    		N/A
    		Comments:










    		DataDict.m file














































    		Calibration port initialization values match







    		Yes
    		Comments:










    		DataDict.m file










    		Hard coded values are assigned in the start of code, No changes made in this version

































    Components not using application data types:























    		Sender/Receiver port initialization values match







    		N/A
    		Comments:










    		DataDict.m file and have been converted to counts






















    		for fixed point types














































    		Calibration port initialization values match







    		N/A
    		Comments:










    		DataDict.m file and have been converted to counts






















    		for fixed point types














































    		Mapping set and all unused items have been







    		Yes
    		Comments:










    		removed













































    All sender/receiver port read/writes using direct








    		Yes
    		Comments:










    		read/writes(List justification if not)













































    Runnable calling frequencies match FDD








    		Yes
    		Comments:

































    DataDict.m display variables: created as








    		No
    		Comments:









    PerInstanceMemory. Matches the FDD











    		Please refer below comment, No changes made in this version

































    Component is correct component type








    		Yes
    		Comments:











































































    		General Notes / Comments:























    		For DFs, it was decided to use the module level variables inplace of PIMs defined in the FDD (PIM section of .m file),
    This is a deviation from regular EA4 process


































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Krishna Anne


    		Review Date :

    		02/08/16
































    		Lead Peer Reviewer:


    		Kathleen Creager


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    Sheet 4: Source Code






















    		Rev 1.28-Jun-15
    Peer Review Meeting Log (Source Code Review)

























    Source File Name:


    		Swp.c

    		Source File Revision:


    		2
    Header File Name:


    		Swp.h

    		Header 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

























    MDD Name:

    		Swp_MDD

    		Revision:
    		2

























    FDD/SCIR/DSR/FDR/CM Name:




    		DF002A_Swp_Design

    		Revision:
    		1.6.0


























    		Quality Check Items:



































    		Rationale is required for all answers of No









    Working EA4 Software Naming Convention followed:















































    		for variable names







    		Yes
    		Comments:

















































    		for constant names







    		Yes
    		Comments:

















































    		for function names







    		Yes
    		Comments:

















































    		for other names (component, memory







    		Yes
    		Comments:










    		mapping handles, typedefs, etc.)




































    All paths assign a value to outputs, ensuring








    		Yes
    		Comments:









    all outputs are initialized prior to being written





































    Requirements Tracability tags in code match the requirements tracability in the FDD








    		N/A
    		Comments:









    requirements tracability in the FDD











    		Req Tags are not available in the design.
























    All variables are declared at the function level.








    		Yes
    		Comments:
























    Synergy version matches change history





    		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.


    		Yes
    		Comments:



    and Version Control version in file comment block





































    Change log contains detailed description of changes








    		Yes
    		Comments:



    and Work CR number











    		init version
























    Code accurately implements FDD (Document or Model)








    		Yes
    		Comments:










































    Verified no Compiler Errors or Warnings


    		KMC: Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored). Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project should be used; QAC can find compiler errors but not warnings.





    		Yes
    		Comments:
















































    Component.h is included








    		Yes
    		Comments:
























    All other includes are actually needed. (System includes








    		Yes
    		Comments:









    only allowed in Nexteer library components)





































    Software Design and Coding Standards followed:











    		Version:

























    		Code comments are clear, correct, and adequate







    		Yes
    		Comments:










    		and have been updated for the change: [N40] and










    		Deviations exist for DFs

    		all other rules in the same section as rule [N40],






















    		plus [N75], [N12], [N23], [N33], [N37], [N38],






















    		[N48], [N54], [N77], [N79], [N72]














































    		Source file (.c and .h) comment blocks are per







    		Yes
    		Comments:










    		standards and contain correct information: [N41], [N42]





































    		Function comment blocks are per standards and







    		Yes
    		Comments:










    		contain correct information: [N43]





































    		Code formatting (indentation, placement of







    		Yes
    		Comments:










    		braces, etc.) is per standards: [N5], [N55], [N56],













    		[N57], [N58], [N59]














































    		Embedded constants used per standards; no







    		Yes
    		Comments:










    		"magic numbers": [N12]





































    		Memory mapping for non-RTE code







    		Yes
    		Comments:










    		is per standard





































    		All execution-order-dependent code can be







    		Yes
    		Comments:










    		recognized by the compiler: [N80]





































    		All loops have termination conditions that ensure







    		N/A
    		Comments:










    		finite loop iterations: [N63]





































    		All divides protect against divide by zero







    		Yes
    		Comments:










    		if needed: [N65]





































    		All integer division and modulus operations







    		Yes
    		Comments:










    		handle negative numbers correctly: [N76]





































    		All typecasting and fixed point arithmetic,







    		Yes
    		Comments:










    		including all use of fixed point macros and













    		timer functions, is correct and has no possibility






















    		of unintended overflow or underflow: [N66]














































    		All float-to-unsiged conversions ensure the.







    		N/A
    		Comments:










    		float value is non-negative: [N67]





































    		All conversions between signed and unsigned







    		Yes
    		Comments:










    		types handle msb==1 as intended: [N78]





































    		All pointer dereferencing protects against







    		Yes
    		Comments:










    		null pointer if needed: [N70]





































    		Component outputs are limited to the legal range







    		Yes
    		Comments:










    		defined in the FDD DataDict.m file : [N53]





































    		All code is mapped with FDD (all FDD







    		Yes
    		Comments:










    		subfunctions and/or model blocks identified













    		with code comments; all code corresponds to






















    		some FDD subfunction and/or model block): [N40]













































    Review did not identify violations of other








    		Yes
    		Comments:









    coding standard rules





































    Anomaly or Design Work CR created








    		N/A
    		Comments: List Anomaly or CR numbers









    for any FDD corrections needed































































    		General Notes / Comments:
























































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Krishna Anne


    		Review Date :

    		02/08/16
































    		Lead Peer Reviewer:


    		Kathleen Creager


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    Sheet 5: MDD






















    		Rev 1.28-Jun-15
    Peer Review Meeting Log (MDD Review)


























    		MDD Name:

    		Swp_MDD













    		MDD Revision:

    		2


























    		Source File Name:


    		Swp.c











    		Source File Revision:


    		2

    		Source File Name:


    		NA











    		Source File Revision:


    		NA


    		Source File Name:


    		NA











    		Source File Revision:


    		NA



























    		Quality Check Items:




































    		Rationale is required for all answers of No










    		Synergy version matches document








    		Yes
    		Comments:













































    		Change log contains detailed description of changes








    		Yes
    		Comments:













































    		Changes Highlighted (for Unit Tester)








    		Yes
    		Comments:













































    		Diagrams have been included per MDD Guideline








    		Yes
    		Comments:











    		and reviewed






































    		All Design Exceptions and Limitations are listed








    		Yes
    		Comments:



















































    		Design rationale given for all global








    		Yes
    		Comments:











    		data not communicated through RTE ports, per














    		Design and Coding Standards rules [N9] and [N10].















































    		All implementation details that differ from the FDD are








    		Yes
    		Comments:











    		noted and explained in Design Rationale






































    		All Unit Test Considerations have been described








    		Yes
    		Comments:



















































    		General Notes / Comments:



























































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Krishna Anne


    		Review Date :

    		02/08/16
































    		Lead Peer Reviewer:


    		Kathleen Creager


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    Sheet 6: PolySpace






















    		Rev 1.28-Jun-15
    Peer Review Meeting Log (QAC/PolySpace Review)


























    		Source File Name:


    		Swp.c











    		Source File Revision:


    		2

    		Source File Name:


    		NA











    		Source File Revision:


    		NA

    		Source File Name:


    		NA











    		Source File Revision:


    		NA


























    		EA4 Static Analysis Compliance Guideline version:







    		01.01.00














    		Poly Space version:


    		Windows User: eg. 2013b 2103b
    		Polyspace sub project version:




    		Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 TL108A_PolyspaceSuprt_1.0.0

    		QAC version:


    		Windows User: eg 8.1.1-R 8.1.1
    		QAC sub project version:




    		Windows User: eg. TL_100A_1.1.0 TL100A_QACSuprt_1.2.0


























    		Quality Check Items:




































    		Rationale is required for all answers of No



































    		Contract Folder's header files are appropriate and





    		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.


    		Yes
    		Comments:




    		function prototypes match the latest component version







































    		100% Compliance to the EA4 Static AnalysisYes
    		Comments:





    		Compliance Guideline





























    		Are previously added justification and deviation








    		N/A
    		Comments:





    		comments still appropriate






































    		Do all MISRA deviation comments use approved








    		Yes
    		Comments:





    		deviation tags






































    		Cyclomatic complexity and Static path count OK






    		Creager, Kathleen: use Browse Function Metrics, STCYC and STPTH

    		Yes
    		Comments:





    		for all functions in the component per Design














    		and Coding Standards rule [N47]

































































































    		General Notes / Comments:























    		Warning 12.4 occurs as volatile variables are used in logical expressions. Uso of volatiles is by design in order to access them via xcp in non-production builds.

    		QAC and Polyspace archived results were run with SWPENA = STD_ON, but tested with STD_OFF as well































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Krishna Anne


    		Review Date :

    		02/08/16
































    		Lead Peer Reviewer:


    		Kathleen Creager


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    Sheet 7: Integration Manual






















    		Rev 1.28-Jun-15
    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. Swp_IntegrationManual

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





























    		Quality Check Items:




































    		Rationale is required for all answers of No










    		Synergy version matches header








    		Yes
    		Comments:










































    Latest template used








    		Yes
    		Comments:










































    Change log contains detailed description of changes








    		Yes
    		Comments:










































    Changes Highlighted (for Integrator)








    		Yes
    		Comments:











































    		General Notes / Comments:



























































    LN: Intended Use: Identify who were 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. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























    		Change Owner:

    		Krishna Anne


    		Review Date :

    		02/08/16
































    		Lead Peer Reviewer:


    		Kathleen Creager


    		Approved by Reviewer(s):



    		Yes































    		Other Reviewer(s):









































































    5.2 - Swp_IntegrationManual

    Integration Manual

    For

    Swp

    VERSION: 2.0

    DATE: 01-Feb-2016

    Prepared By:

    Krishna Kanth Anne,

    Software Engineering,

    Nexteer Automotive,

    Saginaw, MI, USA

    Location: The official version of this document is stored in the Nexteer Configuration Management System.

    Revision History

    Sl. No.DescriptionAuthorVersionDate
    1Initial versionKrishna Kanth Anne1.020-Oct-15
    2Fix for anomaly EA4#2461Krishna Kanth Anne2.001-Feb-16

    Table of Contents

    1 Abbrevations And Acronyms 4

    2 References 5

    3 Dependencies 6

    3.1 SWCs 6

    3.2 Global Functions(Non RTE) to be provided to Integration Project 6

    4 Configuration REQUIREMeNTS 7

    4.1 Build Time Config 7

    4.2 Configuration Files to be provided by Integration Project 7

    4.3 Da Vinci Parameter Configuration Changes 7

    4.4 DaVinci Interrupt Configuration Changes 7

    4.5 Manual Configuration Changes 7

    5 Integration DATAFLOW REQUIREMENTS 8

    5.1 Required Global Data Inputs 8

    5.2 Required Global Data Outputs 8

    5.3 Specific Include Path present 8

    6 Runnable Scheduling 9

    7 Memory Map REQUIREMENTS 10

    7.1 Mapping 10

    7.2 Usage 10

    7.3 Non RTE NvM Blocks 10

    7.4 RTE NvM Blocks 10

    8 Compiler Settings 11

    8.1 Preprocessor MACRO 11

    8.2 Optimization Settings 11

    9 Appendix 12

    Abbrevations And Acronyms

    AbbreviationDescription
    DFDDesign functional diagram
    MDDModule design Document

    References

    This section lists the title & version of all the documents that are referred for development of this document

    Sr. No.TitleVersion
    1MDD GuidelinesProcess 04.02.00
    2Software Naming ConventionsProcess 04.02.00
    3Coding standardsProcess 04.02.00
    4FDD : DF002A_Swp_DesignSee Synergy Subproject version

    Dependencies

    SWCs

    ModuleRequired Feature
    None

    Global Functions(Non RTE) to be provided to Integration Project

    None

    Configuration REQUIREMeNTS

    Build Time Config

    ModulesNotes
    SwpSet to STD_ON for Sweep software build, set to STD_OFF for normal build. Constant resides in “Swp.h” file.

    Configuration Files to be provided by Integration Project

    None

    Da Vinci Parameter Configuration Changes

    ParameterNotesSWC
    NA

    DaVinci Interrupt Configuration Changes

    ISR NameVIM #Priority DependencyNotes
    NA

    Manual Configuration Changes

    ConstantNotesSWC
    NA

    Integration DATAFLOW REQUIREMENTS

    Required Global Data Inputs

    Please refer DataDict.m file

    Required Global Data Outputs

    Please refer DataDict.m file

    Specific Include Path present

    Swp.h file shall have to be included.

    Runnable Scheduling

    This section specifies the required runnable scheduling.

    InitScheduling RequirementsTrigger
    SwpInit1RTE_Init
    RunnableScheduling RequirementsTrigger
    SwpPer1NoneRTE(2ms)
    RunnableScheduling RequirementsTrigger
    SwpPer2NoneRTE(2ms)

    Memory Map REQUIREMENTS

    Mapping

    Memory SectionContentsNotes
    Swp_START_SEC_CODESwp code and variablesThis code section statement will contain variables that need mapping to GlobalShared memory during Sweep builds (these variables are present when SWPENA == STD_ON)

    * Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.

    Usage

    FeatureRAMROM
    None

    Table 1: ARM Cortex R4 Memory Usage

    NvM Blocks

    None.

    Compiler Settings

    Preprocessor MACRO

    None

    Optimization Settings

    None

    Appendix

    None

    5.3 - Swp_MDD

    Module Design Document

    For

    Swp

    Jan 20, 2016

    Prepared For:

    Software Engineering

    Nexteer Automotive,

    Saginaw, MI, USA

    Prepared By:

    Krishna Kanth Anne,

    Nexteer Automotive,

    Saginaw, MI, USA
    Change History

    DescriptionAuthorVersionDate
    Initial VersionKrishna Kanth Anne1.0.020-Oct-2015
    Fix for anomaly EA4#2461Krishna Kanth Anne1.1.020-Jan-2016


    Table of Contents

    1 Introduction 4

    1.1 Purpose 4

    1.2 Scope 4

    2 PullCmpActv & High-Level Description 5

    3 Design details of software module 6

    3.1 Graphical representation of PullCmpActv 6

    3.2 Data Flow Diagram 6

    3.2.1 Component level DFD 6

    3.2.2 Function level DFD 6

    4 Constant Data Dictionary 7

    4.1 Program (fixed) Constants 7

    4.1.1 Embedded Constants 7

    5 Software Component Implementation 8

    5.1 Sub-Module Functions 8

    5.1.1 Init: SwpInit1 8

    5.1.2 Per: SwpPer1 8

    5.1.3 Per: SwpPer2 8

    5.2 Module Internal (Local) Functions 8

    5.2.1 Local Function #1 8

    5.2.1.1 Design Rationale 8

    5.2.1.2 Processing 8

    6 Known Limitations with Design 9

    7 UNIT TEST CONSIDERATION 10

    Appendix A Abbreviations and Acronyms 11

    Appendix B Glossary 12

    Appendix C References 13

    Introduction

    Purpose

    MDD for Sweep function

    Scope

    NA

    Swp & High-Level Description

    Please refer FDD.

    Design details of software module

    Please refer FDD.

    Graphical representation of Swp

    Data Flow Diagram

    Please refer FDD.

    Component level DFD

    Please refer FDD.

    Function level DFD

    Please refer FDD.

    Constant Data Dictionary

    Program (fixed) Constants

    Embedded Constants

    Local Constants

    Constant NameResolutionUnitsValue
    Please refer DF002A_Swp_DataDict.mNANANA
    SWPSTRT_CNT_U16NANA0
    SWPTRAN_CNT_U16NANA1
    SWPDWELL_CNT_U16NANA2
    SWPSTOP_CNT_U16NANA3
    SWPRAMP_CNT_U16NANA4
    SWPDONE_CNT_U16NANA5

    Software Component Implementation

    Please refer FDD.

    Sub-Module Functions

    Init: SwpInit1

    Please refer FDD.

    Design Rationale

    Dummy Initialization function to correlate with the FDD (.m file)

    Per: SwpPer1

    Please refer FDD.

    Design Rationale

    1. For DFs, it was decided to use the module level variables in place of PIMs defined in the FDD (PIM section of .m file), This is a deviation from regular EA4 process. This is to give control over MemMap to avoid MPU violations while writing these variables using xcp.

    2. All of the given PIMs from .m file are either defined as of Function level variables (if used in only one function) or Module level variables (if used in more than one function) in DFs.

    3. Each of the Function level and Module level variables shall be volatile only when they are intended to be user modifiable as per the data dictionary .m file.

    4. Deviations exist in the naming conventions for all of Function level and Module level variables from regular EA4 naming conventions.

    Per: SwpPer2

    Please refer FDD.

    Design Rationale

    1. For DFs, it was decided to use the module level variables in place of PIMs defined in the FDD (PIM section of .m file), This is a deviation from regular EA4 process. This is to give control over MemMap to avoid MPU violations while writing these variables using xcp.

    2. All of the given PIMs from .m file are either defined as of Function level variables (if used in only one function) or Module level variables (if used in more than one function) in DFs.

    3. Each of the Function level and Module level variables shall be volatile only when they are intended to be user modifiable as per the data dictionary .m file.

    4. Deviations exist in the naming conventions for all of Function level and Module level variables from regular EA4 naming conventions.

    Known Limitations with Design

    None.

    UNIT TEST CONSIDERATION

    1. Please refer Init.txt file in the FDD design: DF002A_Swp_Design for initial values of Function level and Module level variables.

    2. For DFs, it was decided to use the module level variables in place of PIMs defined in the FDD (PIM section of .m file), This is a deviation from regular EA4 process.

    3. All of the given PIMs from .m file are either defined as of Function level variables (if used in only one function) or Module level variables (if used in more than one function) in DFs.

    4. Each of the Function level and Module level variables shall be volatile only when they are intended to be user modifiable as per the data dictionary .m file.

    5. Deviations exist in the naming conventions for all of Function level and Module level variables from regular EA4 naming conventions.

    Abbreviations and Acronyms

    Abbreviation or AcronymDescription

    Glossary

    Note: Terms and definitions from the source “Nexteer Automotive” take precedence over all other definitions of the same term. Terms and definitions from the source “Nexteer Automotive” are formulated from multiple sources, including the following:

    • ISO 9000

    • ISO/IEC 12207

    • ISO/IEC 15504

    • Automotive SPICE® Process Reference Model (PRM)

    • Automotive SPICE® Process Assessment Model (PAM)

    • ISO/IEC 15288

    • ISO 26262

    • IEEE Standards

    • SWEBOK

    • PMBOK

    • Existing Nexteer Automotive documentation

    TermDefinitionSource
    MDDModule Design Document
    DFDData Flow Diagram

    References

    Ref. #TitleVersion
    1AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)v1.3.0 R4.0 Rev 2
    2MDD GuidelineEA4 01.00.00
    3Software Naming Conventions.doc1.0
    4Software Design and Coding Standards.doc2.0
    5FDD: SF002A_Swp_DesignSee Synergy SubProject version