Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 66 views

    Planning Model Architecture and Modeling Patterns For Iso 26262 Compliance

    Uploaded by

    Atharva Joshi.
    This document discusses best practices for using Simulink models to develop automotive safety-critical software according to ISO 26262. It recommends splitting models into hierarchical units referenced from a top-level architecture, protecting data between safety levels, and using metrics to monitor unit complexity. The document also addresses challenges like achieving functional safety and efficiency standards, and notes that the discussed patterns are compatible with AUTOSAR architectures.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Planning Model Architecture and Modeling Patterns For Iso 26262 Compliance

    Uploaded by

    Atharva Joshi.
    66 views17 pages
    This document discusses best practices for using Simulink models to develop automotive safety-critical software according to ISO 26262. It recommends splitting models into hierarchical units referenced from a top-level architecture, protecting data between safety levels, and using metrics to monitor unit complexity. The document also addresses challenges like achieving functional safety and efficiency standards, and notes that the discussed patterns are compatible with AUTOSAR architectures.

    Original Description:

    Planning Model Architecture and Modeling Patterns for Iso 26262 Compliance

    Original Title

    Planning Model Architecture and Modeling Patterns for Iso 26262 Compliance

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document discusses best practices for using Simulink models to develop automotive safety-critical software according to ISO 26262. It recommends splitting models into hierarchical units referenced from a top-level architecture, protecting data between safety levels, and using metrics to monitor unit complexity. The document also addresses challenges like achieving functional safety and efficiency standards, and notes that the discussed patterns are compatible with AUTOSAR architectures.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    66 views17 pages

    Planning Model Architecture and Modeling Patterns For Iso 26262 Compliance

    Uploaded by

    Atharva Joshi.
    This document discusses best practices for using Simulink models to develop automotive safety-critical software according to ISO 26262. It recommends splitting models into hierarchical units referenced from a top-level architecture, protecting data between safety levels, and using metrics to monitor unit complexity. The document also addresses challenges like achieving functional safety and efficiency standards, and notes that the discussed patterns are compatible with AUTOSAR architectures.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 17

    Simulink Model Architecture and Modeling Patterns for

    ISO 26262 Compliance

    Jason Moore - MathWorks Consulting

    © 2019 The MathWorks, Inc.


    1
    ISO 26262 “Road Vehicles - Functional Safety”

    ▪ ISO 26262 is a functional safety standard for road vehicles

    ▪ MathWorks has seen an increased interest in ISO 26262 compliant


    workflows
    – Increase in System Complexity
    – Demand from ADAS and AD related applications

    ▪ ISO 26262 facilitates modern software engineering concepts such as


    – Model-Based Design

    2
    Challenges with ISO 26262

    ▪ Do I have an ISO 26262 compliant workflow?

    ▪ How to efficiently reach unit testing coverage criteria?

    ▪ How to achieve Freedom from Interference?

    ▪ Can we use AUTOSAR and meet ISO 26262 at the same time?

    ▪ Is Simulink suitable for use for ISO 26262?

    3
    ISO 26262-6:2018 notes Simulink and Stateflow as Suitable for
    Software Architecture, Design and as basis for Code Generation

    Table 2 Software Architecture Design Notations has similar suitability wording for use of Simulink and Stateflow
    4
    MathWorks Support

    ▪ IEC Certification Kit


    – Model-Based Design Reference Workflow
    ▪ Proven in use
    – Tool Qualification Package
    ▪ Software Tool Criteria Evaluation Report
    ▪ Software Tool Qualification
    ▪ Tool Validation Suite

    5
    MathWorks Support

    ISO 26262 Consulting Services

    ▪ Process establishment
    – Development Processes
    – Verification process
    – Gap analysis

    ▪ Tool qualification support


    – Analyze customer specific tools
    – Provide guidance on tool qualification
    activities

    6
    Certification Kit and Consulting Services

    Mapping

    High-Level
    Workflow
    ▪ Certification Kit maps to ISO
    26262.
    – Focuses on high level workflow
    – Allows user to decide
    implementation details
    ▪ MathWorks Consulting Services
    – Focuses on customizing implementation
    Implementation
    – Provide recommendations
    MathWorks Consulting Services
    7
    Certification Kit and Consulting Services

    ▪ Through numerous engagements, we have


    found a set of common Simulink model
    architecture related Best Practices. High-Level
    Workflow
    ▪ Best Practices assume a “top down” code
    generation approach.

    ▪ Example modeling patterns shown are an Architecture


    related Best
    “enablers” to meeting ISO 26262.
    Practice

    Implementation
    MathWorks Consulting Services
    8
    Best Practices

    ▪ Architecture
    ▪ Signal Routing
    ▪ Data Definition
    ▪ Code Generation Configuration

    ▪ Modeling Best Practice for ISO 26262


    – Paper
    – Please request www.mathworks.com/services/consulting/contact.html

    9
    Use Model Metrics to Monitor Unit Complexity
    Architecture
    Model Metric Dashboard
    ▪ Issues:
    – Model verification gets increasingly difficult
    – Unable to efficiently achieve unit coverage
    ▪ Best Practice:
    – Define complexity metrics
    ▪ Number of I/O
    ▪ Reusable libraries
    ▪ Cyclomatic complexity (<=30)*
    ▪ Number of elements (<500)*
    ▪ …etc.
    – Monitor coverage metrics using Continuous
    Integration tools.
    ▪ Reference:
    – *Paper: Model Quality Objectives
    ▪ Authors: Jérôme Bouquet(Renault), Stéphane Faure(Valeo), Florent Fève(Valeo), Ursula Garcia(Bosch),
    François Guérin(MathWorks), Thierry Hubert(PSA), Florian Levy(Renault), Stéphane Louvet(Bosch), Patrick
    Munier(MathWorks), Pierre-Nicolas Paton(Delphi), Alain Spiewek(Delphi), and Yves Touzeau(Renault)
    10
    Use Model Reference for Unit Level Model
    Simulink Architecture

    ▪ Issues:
    – Poor modularity of algorithm (reuse)
    – Unable to preform unit level testing
    – Configuration Management difficulties
    – Unable to achieve Freedom from
    Interference
    Model block as
    ▪ Best Practice Unit containers
    – Use Model Reference for unit level
    model
    – Group units to form functional hierarchy
    Group Units with
    (features/components) with virtual Subsystem block
    Subsystems

    11
    Split ASIL and QM Levels at Top Level of Control Model
    Simulink Architecture

    ▪ Issues:
    – Difficulty in achieving Freedom from
    Interference
    – Complexity in code integration
    ▪ Best Practice:
    – Code generation should be done at as high as
    level as possible.

    Model Hierarchy Modeling Pattern …


    Top level (ASIL / QM) Model Reference
    Integration Subsystem (multiple layers)
    Unit Model Reference

    12
    Data Protection Between ASIL and QM Levels
    Code Generation Configuration

    ▪ Issues:
    – How to provide signal protection between ASIL and
    QM functions?
    ▪ Best Practice
    – Use Get/Set storage class for signals between ASIL
    and QM levels

    13
    Data Protection Between ASIL and QM Levels
    Code Generation Configuration
    Get/Set Storage Class
    ▪ Issues:
    – How to provide signal protection between ASIL and
    QM functions?
    ▪ Best Practice
    – Use Get/Set storage class for signals between ASIL
    and QM levels

    14
    Design Bus Hierarchy
    Signal Routing

    ▪ Issues:
    – Inefficient bus segmentation
    – Inconsistent bus grouping by
    developers
    – Modeling difficulty from splitting and
    recreating bus signals
    ▪ Best Practice:
    – Bus hierarchy should be designed as a
    function of ASIL levels, QM, and rates at
    a minimum.

    15
    AUTOSAR Implications

    ▪ Best Practices shown are compatible to AUTOSAR

    ▪ Many of the configuration and customization can be implemented within an


    AUTOSAR architecture

    ▪ AUTOSAR addresses some of the issues listed


    Application Layer
    above. For example:
    – Get/Set function would be implemented using SWC1 SWC2 SWC…
    Send/Receiver port with RTE protection
    Run Time Environment (RTE)

    ▪ Reference Workflow shown in IEC Certification Basic Software


    Kit supports AUTOSAR architecture
    Layered AUTOSAR Architecture
    16
    Summary

    ▪ Best Practice based on Consulting Engagements


    ▪ Modeling Best Practice for ISO 26262
    • Use Model Reference for Unit Level Model • Modeling Construct for Data
    • Split ASIL and QM Levels at Top Level of Model • Data Protection Between ASIL and QM Levels
    • Eliminate Algorithm Content at Integration Level • Partition Different ASIL levels and QM to Separate
    • Use Model Metrics to Monitor Unit Complexity Memory Section
    • Pass Only Used Signal into Unit • Use Different Name Token for Shared Utility
    • Design Bus Hierarchy • AUTOSAR Implications

    ▪ Paper
    – Please request via www.mathworks.com/services/consulting/contact.html

    ▪ ISO 26262 booth

    17

    You might also like