Methodology Handbook Efficient Avionics Systems Engineering with ARP-4754A Objectives Using SCADE System® First Edition CONTACTS
Headquarters
Esterel Technologies SA Submit questions to Technical Support at scade- Parc Euclide - 8, rue Blaise Pascal [email protected]. 78990 Elancourt FRANCE Contact one of our Sales representatives at scade- [email protected]. Phone: +33 1 30 68 61 60 Fax: +33 1 30 68 61 61 Direct general questions about Esterel Technologies to [email protected].
Discover latest news on our products and technology at www.esterel-technologies.com.
LOCAL SUPPORT SITES
United States Southern Europe
1082 North Alafaya Trail Esterel Technologies SA Suite 124 Park Avenue - 9, rue Michel Labrousse FL 32826 Orlando 31100 Toulouse United States FRANCE Phone: +1 724-514-2997 Phone: +33 5 34 60 90 50
Central Europe China
Esterel Technologies GmbH Esterel Technologies Otto-Hahn-Strasse 13b 1303, Jiaxing Mansion Ottobrunn - Riemerling 877, Dongfang Road D- 85521 München 200122, Shanghai GERMANY P.R. CHINA Phone: +49 89 608 75530 Phone: +86 21 61050287
DISCLAIMER: The content of this handbook is distributed for informational use only, is subject to change without notice, and should not be construed as a complete and contractual information from Esterel Technologies SA for developing fully certified software. Although every precaution has been taken to prepare this handbook, Esterel Technologies assumes no responsibility or liability for any errors that may be contained in this book or any damages resulting from the use of the information contained herein.
© 2013 Esterel Technologies - A wholly-owned subsidiary of ANSYS, Inc. All rights reserved Esterel Technologies SA. SCADE®, SCADE System®, SCADE Suite®, SCADE Display®, and SCADE LifeCycle® are registered trademarks of Esterel Technologies.
Shipping date: June 2013 Revision: SSY-HB-ARP4754 - DOC/rev/26003-07 SCADE System with ARP-4754A Objectives
Abstract
This handbook addresses the issues of process, structuring, and productivity in systems engineering for avionics applications. Such projects, driven by the ARP-4754A guidelines, traditionally require iterative multi-disciplinary tasks, incurring high verification efforts and high attention to the preservation of system definition integrity. The handbook reviews the regulatory guidelines and then presents the optimization of the development and verification processes that can be achieved with the SCADE System® methodology and tools, coming with the whole software development capabilities of SCADE Suite® and SCADE Display®, the lifecycle management capabilities of SCADE LifeCycle®, and the multi-domain simulation capabilities of ANSYS® Simplorer®. SCADE System enables the correct allocation of requirements to a given development item and produces architecture, interfaces, and data dictionaries for the various development teams that together build an aircraft system.
Methodology Handbook
SCADE System with ARP-4754A Objectives
Table of Contents
1. Introduction 1 1.1 Background, Objectives, and Scope 1 1.2 Presentation 2
2. Systems Engineering 3 2.1 What is a System 3 2.2 Definition of Systems Engineering 4 2.3 Systems Engineering Management 5 2.4 Systems Engineering Process 6 2.5 From System Requirements to Architecture Definition 7 2.6 Detailed Design and Implementation 9 2.7 Integration, Verification, and Validation 9
3. ARP-4754A 13 3.1 The Standard 13 3.2 Aircraft and System Development Process 13 3.2.1 Aircraft Function Development 14 3.2.2 Allocation of Aircraft Functions to Systems 14 3.2.3 Development of the System Architecture 15 3.2.4 Allocation of System Requirements to Items 15 3.2.5 System Implementation 15 3.3 Integral Process 17 3.3.1 Safety Assessment 18 3.3.2 Development Assurance Level Assignment 19 3.3.3 Requirements Capture 20 3.3.4 Requirements Validation 20 3.3.5 Implementation Verification 21 3.3.6 Configuration Management 21 3.3.7 Process Assurance 21 3.3.8 Certification Coordination 22
4. SCADE Model-Based Systems Engineering 23 4.1 Definition of MBSE 23
Methodology Handbook i SCADE System with ARP-4754A Objectives
Table of Contents
4.2 Simulation Driven Product Development 26 4.3 SCADE System Features Overview 30 4.3.1 Model and Package 31 4.3.2 Block Diagram 32 4.3.3 Allocation Tables 33 4.3.4 Data Dictionary 35 4.3.5 Model Static Checking 36 4.3.6 Traceability Management 38 4.3.7 Model Documentation Generation 39 4.3.8 System-Software Synchronization 40
5. SCADE Model-Based Systems Engineering Process 41 5.1 SCADE Model-Based Systems Engineering V-Cycle 41 5.2 Requirements Analysis 42 5.2.1 Requirements Elicitation 43 5.2.2 Operational Analysis 44 5.2.3 Prototyping the Operations 47 5.2.4 A Focus on Derived Requirements 48 5.3 Functional Decomposition 48 5.4 Requirements Validation 51 5.4.1 Completeness Checks 51 5.4.2 Correctness Checks 52 5.4.3 Prototyping Functions for Correctness Check 52 5.4.4 Focus on Assumptions Validation 53 5.5 Architecture Definition 54 5.5.1 Architecture Modeling 54 5.5.2 Relationship with Safety Analysis 56 5.6 Architecture Validation 57 5.7 Allocations 58 5.7.1 Allocation of Requirements to Functions 59 5.7.2 Allocation of Functions to Items 61 5.7.3 Allocation of Requirements to Items 62 5.8 Dissemination of Interfaces and Data 62 5.8.1 System/Software Synchronization 63
Methodology Handbook ii SCADE System with ARP-4754A Objectives
Table of Contents
5.9 Data Dictionary Management 64 5.10 ARP-475A A-1 Table: Sections Related to Requirements 65 5.11 Item Modeling 68 5.12 Item Implementation 70 5.13 Integration and Verification and Validation 72 5.14 ARP-475A Tables Related to Implementation, Integration, and V&V 76
6. Conclusions 79
Appendixes and Index 83
A ARP-4754A Integral Process Tables 85 B References 91 C Acronyms and Glossary 93 D Software Simulation with SCADE Suite, SCADE Display, and ANSYS Simplorer 97 INDEX 99
Methodology Handbook iii
SCADE System with ARP-4754A Objectives
List of Figures
Figure 2.1: What is a system 3
Figure 2.2: Systems engineering management 5
Figure 2.3: Typical systems engineering process 6
Figure 2.4: Technical activities from Requirement to Architecture selection 7
Figure 2.5: Progressive nature of integration 10
Figure 2.6: System Verification and Validation 11
Figure 3.1: Global view of the ARP-4754 positioning 13
Figure 3.2: System Development Process according to ARP-4754A 14
Figure 3.3: ARP-4754A Integral Process 17
Figure 3.4: System Engineering Process and Safety compliant with ARP-4754A 18
Figure 4.1: Problem of consistency along the development process 23
Figure 4.2: Driven by models 25
Figure 4.3: Engineering practices and owners 27
Figure 4.4: ANSYS / Esterel Technologies Systems Engineering solution map 28
Figure 4.5: Virtual system integration and V&V with ANSYS tools 29
Figure 4.6: Designing with SCADE System 30
Figure 4.7: Model and package in SCADE System 31
Figure 4.8: Block Diagram in SCADE System 32
Figure 4.9: Allocation tables in SCADE System 33
Figure 4.10: Allocation in Properties 34
Figure 4.11: Data dictionary in SCADE System 35
Figure 4.12: Allocation of additional data to connections between blocks 36
Figure 4.13: List of rules available for static checking 36
Figure 4.14: SCADE System Checker 37
Methodology Handbook v SCADE System with ARP-4754A Objectives
List of Figures
Figure 4.15: Traceability management in SCADE System 38
Figure 4.16: Complete documentation generation in SCADE System 39
Figure 4.17: Synchronization with SCADE Suite 40
Figure 5.1: ARP-4754A compliant SCADE MBSE V-Cycle (System Level) 42
Figure 5.2: Requirements elicitation process 43
Figure 5.3: Operational Analysis 45
Figure 5.4: Top-level model in SCADE System 46
Figure 5.5: Prototyping operations 47
Figure 5.6: Functional Decomposition versus Architectural Definitions 48
Figure 5.7: Functional decomposition of an aircraft system 49
Figure 5.8: SCADE System Checker run on an aircraft system model 50
Figure 5.9: Requirements Management Gateway coverage measurement 51
Figure 5.10: Engineering peer review process 52
Figure 5.11: Prototyping of functions 53
Figure 5.12: Architecture definition of the Fighter Mission system 56
Figure 5.13: Local FMEA at block level 57
Figure 5.14: Several types of allocations 58
Figure 5.15: Requirements Management Gateway links between requirements and functions 59
Figure 5.16: Requirements Management Gateway coverage of requirements by functions 60
Figure 5.17: Requirements Management Gateway impact analysis between requirements and functions 60
Figure 5.18: Allocation table of functions to items: an efficient way to manage functional decomposition 61
Figure 5.19: Requirements Management Gateway links between requirements and items 62
Figure 5.20: System – Software Synchronization: System Model in SCADE System 63
Methodology Handbook vi SCADE System with ARP-4754A Objectives
List of Figures
Figure 5.21: Data Dictionary in SCADE System 64
Figure 5.22: 3D models and 0D models 68
Figure 5.23: Simulation in Simplorer 69
Figure 5.24: Simulation of SCADE Display Application (UAV Ground Station Control) 70
Figure 5.25: Virtual integration of SCADE Suite application in Simplorer simulation 73
Figure 5.26: Power of ROM 74
Figure 5.27: Example of HIL simulation with NI LabVIEW and SCADE System 75
Figure D.1: Software modeling with SCADE Suite 97
Figure D.2: HMI modeling with SCADE Display 97
Figure D.3: Managing Requirements with SCADE LifeCycle 98
Figure D.4: Conceptual analysis and virtual prototyping with ANSYS tools 98
Methodology Handbook vii
SCADE System with ARP-4754A Objectives
List of Tables
Table 3.1: DAL assignment levels by aircraft function 19
Table 3.2: List of certification data at system level 22
Table 5.1: Development Processes by standard 71
Table 5.2: Integral and Supporting Processes by standard 71
Table A.1: Process Objectives, Outputs, and System Control Category 86
Methodology Handbook ix
SCADE System with ARP-4754A Objectives
1. Introduction
SCADE MBSE solutions are organized around 1.1 Background, Objectives, and SCADE System and its SysML-based notation. Scope Demonstration is made that the carefully selected subset of SysML supported by SCADE System allows system engineers to stay focused Before all professions involved in the Systems on their functional and architectural designs, Engineering process come on board, a small avoiding the complexity of the UML/SysML integrated team gets the extremely sensitive duty language. to establish what the system should look like at the end. The handbook shows how MBSE handles the key objective of validating the requirements and This team must produce all the necessary highlights how the features of SCADE System artifacts for all the interdisciplinary teams that facilitate the daily engineering duties, such as will work on the System development. Systems integrity checking, traceability management, Engineering is about creating a system and a allocation management, integrating changes, and plan for it. It is not only a question of reporting. conception but also a question of maintaining the integrity of the system throughout its life The handbook also explains how SCADE cycle. MBSE solutions allow for carefully and safely meeting the objectives of the tables in the ARP- In this handbook, Model-Based Systems 4754A standard [ARP-4754A]. Engineering (MBSE) is described as an efficient deployed technique that sets modeling as the Modeling allows simulation: ANSYS / Esterel primary source of data all along the system Technologies Simulation-Driven Product development life cycle to improve Development (SDPD) solution is described as communication with stakeholders and within the unique optimized solution able to interrelate engineering project teams, to identify early functional, 0-D and 3-D simulation tools. system requirements issues, to enhance design Virtual simulation is admittedly able to reduce rigor and integrity, to increase productivity from the number of errors found during physical impact analysis of requirement changes to the integration and verification activities. reuse of registered models, to reduce risks by enabling requirements validation prior to implementations.
Methodology Handbook 1 - 1 SCADE System with ARP-4754A Objectives
application of MBSE methodology and tools is 1.2 Presentation detailed. Attention is paid to the elaboration of System Requirements, which is the primary objective of the Systems Engineering process. This document provides a careful explanation of Integration, Verification, and Validation the system life cycles as described in the ARP- activities are handled as well. 4754A guidelines. It provides explanations on how model-based techniques enable safe, Section 6. This section draws conclusions that secure, productive systems engineering sum up the major benefits of using the SCADE practices. Model-Based Systems Engineering approach. The document is organized as follows: Appendix A lists and substantiates the ARP- 4754A tables of objectives data according to the Section 2. This section provides an overview of Integral Processes determined by the standard. the systems engineering life cycle and commonly used best practices Appendix B provides the list of references. Section 3. This section carefully summarizes the Appendix C lists all acronyms in use in this major statements, recommendations, and rules document and defines key terminology in a described in the AR-4754A standard: “Guidelines glossary. for Development of Civil Aircraft and Systems”. Appendix D briefly describes SCADE Suite, Section 4. This section shows the SCADE SCADE Display, and ANSYS Simplorer tools. Model-Based Systems Engineering (MBSE) Note that the content of this document applies approach, focusing particularly on the SCADE to the following products: MBSE V-cycle and on Model-Based tools, • SCADE System being at the center. SCADE System 2.0 • SCADE LifeCycle 6.4 Section 5. This section thoroughly develops the • SCADE Suite 6.4 processes and methodology expounded in the • SCADE MBSE V-cycle. For each process, the SCADE Display 6.4 • Simplorer 11.0
Methodology Handbook 1 - 2 SCADE System with ARP-4754A Objectives
2. Systems Engineering
A system has a boundary that depends on the 2.1 What is a System focus defined by its objective. For example, if the objective of the system is “to provide runway centerline guidance to the aircraft when landing”, the Broadly, a system is a set of interacting system is a localizer. But, if the system is meant components that achieves an objective (Figure “to provide precision guidance to an aircraft approaching 2.1). While achieving its objective, a system and landing on a runway”, the system is an provides a service to a user (or services to Instrumented Landing System (ILS), that is several users), it interfaces with operators, and it basically made of two localizers (one lateral, one works within its environment that is regulating vertical). its operation. When defining the boundary of a system, one The objective of the system is to process exactly defines what crosses it, including what is and correctly the inputs, the actualization of the expected (defined inputs and outputs of the functional requirements, and the expression of system, resources, etc.) and what is not (e.g., outputs. To fulfill the objective, the system has events that can damage the achievement of the to overcome outside forces like Environment, objective such as interferences, shocks, etc.). Boundary Crossing, and Interacting Systems.
Environment conditions and exposures Interacting actors and systems Environment Regulatory rules and other standards … System Boundary Objective Mission to accomplish users expectations System
Interacting C1 C2 Components Operators Inputs Outputs Operators Resources Users
Including: performance C3 objectives met, safety objectives met, ... Boundary Crossing Interacting System Inputs & outputs Systems Interferences (electromagnetics,…) Shocks and vibrations Energy transfer Thermal flow …
Figure 2.1: What is a system
Methodology Handbook 2 - 3 SCADE System with ARP-4754A Objectives
So a system is defined by what it is doing. That Systems engineering is primarily a global view is why Systems Engineering best practices are that is managing complexity. primarily relying on requirements, scenarios of Systems engineering aims at implementing a use, and function decomposition, as described top-down approach but also making a provision in the next chapters. for reuse in a bottom-up approach. Systems Engineering requires contribution from 2.2 Definition of Systems extremely diverse technical disciplines. Thus, Engineering decomposing the whole into components and characterizing the interactions among these components is a key to success of Systems “Systems engineering is an interdisciplinary approach engineering. and means to enable the realization of successful systems. It focuses on defining customer needs and required Systems engineering is both a technical and a functionality early in the development cycle, documenting management process, together iterative and requirements, and then proceeding with design synthesis incremental. and system validation while considering the complete Technical process: develop physical systems that problem: operations, cost and schedule, performance, satisfy the customers’ needs. It encompasses the training and support, test, manufacturing, and disposal. design, development, production and operation Systems engineering integrates all the disciplines and of these systems. specialty groups into a team effort forming a structured development process that proceeds from concept to Management process: organize the technical production to operation. Systems engineering considers efforts in the appropriate lifecycle. Its nature is both the business and the technical needs of all customers mainly oriented towards problem solving. with the goal of providing a quality product that meets Systems engineering is constantly looking to the user needs.” [INCOSE] increase the probability of success, reducing risks, managing safety and reliability, and Systems engineering is… “An interdisciplinary, optimizing the global life cycle cost. collaborative approach that derives, evolves, and verifies a life-cycle balanced system solution which satisfies customer expectations and meets public acceptability.” [IEEE P1220]
Methodology Handbook 2 - 4 SCADE System with ARP-4754A Objectives
baselining, from initial concept to the 2.3 Systems Engineering implemented, integrated, verified, and validated Management system. The project must be defined and plans issued. Project Plans encompass Statements of Work, As illustrated in Figure 2.2 below, three major Development Plan, Verification & Validation activities contribute to Systems Engineering Plan, Quality Assurance, Safety and Certification Management. Plans, Configuration Management and Project Development Planning and Control is the Schedule. management process that governs the technical processes and provides steps and progressive
Development Planning & Control
Baselining Life Cycle Planning
Managing Systems Life Cycle Engineering Integration Integrated Teaming
Figure 2.2: Systems engineering management
The project must be carefully controlled (regular management. Decision making is an essential assessments and corrective actions) as Systems part of the process, must be precisely defined Engineering is basically a problem solving and planned, and must be based on trustable method. It requires both agility and formal data from the interdisciplinary teams.
Methodology Handbook 2 - 5 SCADE System with ARP-4754A Objectives
Lifecycle Integration is the necessary process that ensures that the developed system is viable 2.4 Systems Engineering Process all along its life cycle. It involves the multidisciplinary teams and the customers/ users. The objective of this management process There are multiple ways to show a Systems is to streamline the interactions among teams, to Engineering process. Figure 2.3 below shows a ensure the incorporation of inputs from V-Cycle representation. specialized areas such as safety, risk The V-Cycle is a natural representation of the management, business, resource allocation, and design process that firstly shows a top to finance in the system development project bottom path, from the establishment of the management. system requirements to the design of The Systems Engineering Process represents the components, followed by a bottom to top technical core process. This is the main subject recovery path that enables step by step of this document that is detailed in the integrations and verification and validation following chapters. activities. Basically, the Systems Engineering process is mainly a top-down, comprehensive problem- solving process. But it is as well iterative and recursive as described in the next sections.
System Requirements System Validation Analysis
System Functional System Verification Decomposition
System Architecture System Integration Definition
Detailed Design, Implementation & Optimization
Figure 2.3: Typical systems engineering process
Methodology Handbook 2 - 6 SCADE System with ARP-4754A Objectives
As shown in Figure 2.4 below, this portion of 2.5 From System Requirements to the Systems Engineering process covers the Architecture Definition following main connected activities: • Requirements Analysis • Functional Decomposition This section covers the System Requirement Analysis and System Functional & Architecture • Architectures Design Design processes of the above V-cycle (Figure • Synthesis and Selection 2.3). These activities are both technically-driven and management-driven. Requirements are the primary focus of the systems engineering process (systems engineering process shortened purpose is to transform requirements into designs).
Users Needs Requirements Analysis Allocation
Functional Decomposition Allocation Verification
Requirements Functions Architectures Architectures Design
Synthesis & Selection Verification
Figure 2.4: Technical activities from Requirement to Architecture selection
A set of top-level stakeholders needs, objectives functional requirements. An initial and requirements, sometimes informal, are representation of a future system is built that translated into product functional and non- does not imply any specific implementation.
Methodology Handbook 2 - 7 SCADE System with ARP-4754A Objectives
These requirements can lead to a few alternate Functional Decomposition activities include: architectures and designs for the end product. • Decompose requirements to a hierarchy of Each requirement is iteratively examined for functions validity, consistency, desirability and • Allocate performance and other constraints to all attainability. With these examinations, or functional levels evaluations, a decision can be made on the • Define functional architecture design. • Manage traceability between Requirements and The selection of the preferred System Functions Architecture is essentially a trade-off among the • Define functional interfaces various architecture options. The selected Architectures Design activities include: baseline System Architecture should be robust • Define physical architecture implementing the and satisfactory close to the theoretical functions optimum in meeting requirements, with • acceptable risk and within available resources Define alternative architecture concepts and budget. • Allocate Functions to Components of the architecture Process inputs include: • Manage traceability between Requirements and • Users’ needs, objectives and requirements Components • Technology base • Define physical interfaces • Standards Synthesis and Selection activities include: • Requirements from prior developments • Study trade-offs • Program decision requirements • Manage risks, safety and performance Requirements Analysis activities include: • Select preferred architecture • Elicit the requirements, creating the set of • Make and report decision requirements from the needs expressed by users • Set up configuration, baselines, traceability and all and other stakeholders necessary data • Analyze the concept of operations (missions of the • Verify the selected architecture: costs analysis, system) COTS, reuse of in-house or COTS components, • Identify the environmental constraints and impact of organization are taken into consideration standards that are limiting the solutions for the selection of the appropriate architecture • Identify the functional and non-functional Process Outputs include: requirements • Decision database • Validate the requirements, determining their • Selected architecture of components completeness and correctness • Specifications and baselines
Methodology Handbook 2 - 8 SCADE System with ARP-4754A Objectives
2.6 Detailed Design and 2.7 Integration, Verification, and Implementation Validation
This section covers the System Design and This section handles the Component Integration detailed Design & Optimization processes of & Verification, System Integration & the above V-cycle (Figure 2.3). Verification, and System Validation processes. This is the Implementation part of the overall “The purpose of the Integration Process is to assemble a Systems Engineering process. system that is consistent with the architectural design. This process combines system elements to form complete “During the Implementation Process, engineers follow the or partial system configurations in order to create a requirements allocated to the system element to design, product specified in the system requirements. [...] The fabricate, code, or build each individual element using purpose of the Verification Process is to confirm that the specified materials, processes, physical or logical specified design requirements are fulfilled by the system. arrangements, standards, technologies, and/or This process provides the information required to effect information flows outlined in detailed drawings or other the remedial actions that correct non-conformances in the design documentation. Requirements are verified and realized system or the processes that act on it. [...] The stakeholder requirements are validated. If subsequent purpose of the Validation Process is to provide objective configuration audits reveal discrepancies, recursive evidence that the services provided by a system when in interactions occur with predecessor activities or processes, use comply with stakeholders’ requirements, achieving its as required, to correct them.” [INCOSE] intended use in its intended operational environment. The hardware (electromechanical, hydraulic, This process performs a comparative assessment and etc.) and software components (also called: confirms that the stakeholders’ requirements are correctly elements or items) are developed according to defined. [...]. System validation is ratified by the appropriate process standards. stakeholders.” [ISO/IEC15288] Please consult our Model-Based Software As shown in Figure 2.5 below, integration is Development and Verification handbooks for iterative and progressive. Each level of software components that are developed with integration is built on the top of the previous SCADE Suite and SCADE Display. level of tested integration. It is essential that interfaces between components, between sub-systems, and between the system and other systems and/or its environment are well known.
Methodology Handbook 2 - 9 SCADE System with ARP-4754A Objectives
Defining and maintaining those interfaces is a primary responsibility of Systems Engineering.
Components Sub-Systems System
A1 Test A1
A2 Test A2 A Test A A3 Test A3 Integration
A4 Test A4
B Test B System Integration
C Test C
Figure 2.5: Progressive nature of integration
Figure 2.6 below shows the difference between • Demonstration: a set of inputs that is sufficiently Verification and Validation and how testing covering the expected operation is used to activities are doing both. demonstrate that the required functions are performed System Verification ensures that the system has • Test: tests are conducted with respect to the been built correctly. requirements and are meant to obtain accurate Verification techniques involve: quantitative results that can be analyzed against expected accurate results • Inspection: engineer performs an examination of System Validation ensures that the built system the system against the requirements (useful for observable properties such as: color, weight, etc.) is the right system. This is why users and other project stakeholders are involved. In particular, • Analysis: it is used when real conditions of the the built system must achieve the business goal verification cannot be established. Analytical data are used or simulation in very precisely defined which determines that the initial concept has conditions is performed been transformed into an operational system.
Methodology Handbook 2 - 10 SCADE System with ARP-4754A Objectives
Validation is concerned with checking that the Validation starts early in the process as it system meets the customer’s actual needs. includes activities, such as requirements Validation is a rather subjective process. It modeling (with model analysis) and/or involves making assessments of how well the simulation/prototyping for user evaluation. (proposed) system addresses a real-world need.
Verification Validation
Testing Integration Acceptance Inspection Test Test Regression Test Beta Test Robustness Test Usability Demonstration System Test Test
Simulation/Prototyping Static Analysis
Robustness Analysis Model Analysis
Figure 2.6: System Verification and Validation
Methodology Handbook 2 - 11
SCADE System with ARP-4754A Objectives
3. ARP-4754A
While the DO-178B/C standard drives the 3.1 The Standard development of software items, the DO-254 drives the development of electronic hardware items.
Safety Assessment Process These standards assume that the requirements Guidelines & Methods are correct and complete, while their assurance ARP 4761 is two-fold as well:
Intended Function, Failure System Aircraft & Safety Design • Develop the software and hardware electronics Function Information Information • Verify that the software and hardware meet their Aircraft & System requirements Development Processes ARP 4754A / ED-79A 3.2 Aircraft and System Development Process Electronic Hardware Software Development Lifecycle Development Lifecycle DO-254 / ED-80 DO-178B / ED-12B ARP-4754A standard primarily focuses on Figure 3.1: Global view of the ARP-4754 positioning establishing good requirements. These requirements are elaborated so that they can be The assurance of ARP-4754A is two-fold: provided to the teams in charge of the • Validate that the requirements are correct and development of items. complete An item is a component of a system that can be • Allocate those requirements to software and developed by a team that manages a given electronic hardware items (“item” is the term used discipline: software, electronic hardware. for component) Figure 3.2 below shows how the ARP 4754A standard represents the global System Development Process.
Methodology Handbook 3 - 13 SCADE System with ARP-4754A Objectives
“Most actual system developments processes involve many System Development Process iterative cycles, making the experience appear more cyclic than sequential. The entry point for aircraft function Aircraft Function Development implementation may occur at any point in the cycle. For a new aircraft-level function, the process begins with the top-level definition of functions. […] In practice many of Allocation of Aircraft Functions to Systems the development activities shown […] are concurrent and may involve interactive dependencies that lead to alteration of previously established requirements.” Development of the System Architecture [ARP-4754A]
Allocation of System Requirements to Items 3.2.2 Allocation of Aircraft Functions to Systems
System Implementation Allocation of Aircraft Functions to Systems consists of grouping aircraft functions and Figure 3.2: System Development Process according to ARP-4754A assigning them to main “systems”. This activity includes functional decomposition. The output of the process is a set of requirements for each 3.2.1 Aircraft Function Development defined system. The standard pinpoints that it is a very Aircraft Function Development is the process important and complex activity: of identifying aircraft-level functions, function “The functional groupings interact with the aircraft requirements, and interfaces. architecture and are the basis for system architecture “Iteration” is the key word of the System development. While it is not necessary to know in detail Development Process. For adding functions to how a system will be implemented to accomplish the an aircraft, the entry point may occur in the necessary functional groupings, implementation context of changes to a particular item. constraints, failure effects and lifecycle support may all play a significant role in selecting the most appropriate groupings.” [ARP-4754A]
Methodology Handbook 3 - 14 SCADE System with ARP-4754A Objectives
Thus, the accomplishment of this allocation 3.2.3 Development of the System means that the appropriate architecture of items Architecture has been selected; this is the architecture that meets requirements while being as close as possible to the other project requirements, Development of the System Architecture is constraints, and opportunities. about building the structure of the interconnected items and boundaries that meet the above defined requirements, including safety 3.2.5 System Implementation requirements and performance requirements. “More than one candidate system architecture may be System Implementation is about developing the considered for implementation. These candidates system items that form the system. Only electronic architecture may be evaluated using such factors as hardware and software items are considered. technology readiness, implementation schedules, This implementation is driven by other producibility, contractual obligations, economics, prior standards: experience, and industry precedence.” [ARP-4754A] “The point where requirements are allocated to hardware and software items is also the point where the guidelines 3.2.4 Allocation of System of this document (ARP 4754A) transition to the Requirements to Items guidance of DO-178B/ED-12B (for software), DO- 254/ED-80 (for electronic hardware), and other industry guidelines. This document provides guidelines for Allocation of System Requirements to Items is architecture, development assurance level, and functional done concurrently to the development of the decomposition including redundancy management. This system architecture. means that the requirement allocation to hardware and/ Several iterations are necessary to solve derived or software has been reached at the point when requirements (i.e., requirements that appear architecture, redundancy management and requirement during design) and make the allocation of decomposition are complete.” [ARP-4754A] requirements to items as clear as possible. It is important to notice that System Iterations can evolve up to refine the system Implementation, as defined by ARP-4754A, functions development and the associated encompasses the hardware and software design/ allocation of functions to the system. build, the electronic hardware/software “The process is complete when all requirements can be integration activities, and the aircraft/system accommodated within the final architecture. The integration activities. decomposition and allocation of requirements to items should also ensure that the item can be shown to fully implement the allocated requirements.” [ARP-4754A]
Methodology Handbook 3 - 15 SCADE System with ARP-4754A Objectives
HARDWARE AND SOFTWARE DESIGN/BUILD “The output is equipment under configuration control “The outputs of this phase include electronic hardware- together with development assurance data and/or software integration procedures, released hardware software life cycle data.” [ARP-4754A] drawings, software source code together with related life AIRCRAFT/SYSTEM INTEGRATION cycle data, applicable development assurance data, breadboard or prototype hardware if applicable, and lab/ System integration is the step-by-step process of flight test articles.” [ARP-4754A] integrating and testing the integration of the items of a system. ELECTRONIC HARDWARE/SOFTWARE INTEGRATION Aircraft Integration’s main duty is to ensure that Mutually prototyping one part for the other, all systems that have been proved to separately virtual simulations, and simulation platforms are operate correctly are still working well together. integration methods considered by the standard.
Methodology Handbook 3 - 16 SCADE System with ARP-4754A Objectives
Figure 3.3 below shows all the process elements 3.3 Integral Process that constitute the Integral Process. It shows at which stage of the engineering development they have interaction: item level, system level, While the overall System Development Process aircraft level. These processes are described in described in Section 3.2 represents the path from the following sections. a concept to implementation, the Integral Process described in this section represents the concurrent processes that have interactions at any stage of the system development.
Development Assurance Aircraft Function Development Level Assignment
Certification Coordination
System Development Safety Assessment
Requirements Capture
Requirements Validation
Implementation Verification
Configuration Management
Process Assurance Item Development
Figure 3.3: ARP-4754A Integral Process
Methodology Handbook 3 - 17 SCADE System with ARP-4754A Objectives
The Safety Assessment process ensures that 3.3.1 Safety Assessment requirements elaborated for safety reasons are correctly and completely considered. This process encompasses a large part of the Details on the Safety Assessment activities are ARP-4754A objectives. It contributes to the provided in the ARP-4761 standard [ARP-4761]. standard’s main focus: establish good Figure 3.4 below shows how the Safety requirements. Assessment activities are interacting with the System Development Process.
Safety Assessment Process System Development Process
Aircraft Function Development Aircraft Functions
FHA Safety Requirements Functional Allocation of Aircraft Functions to Systems Hazard System Functions Analysis CCA Safety Requirements Common Development of the System Architecture Causes PSSA Analysis Preliminary System Safety Assessment Items Requirements Allocation of System Requirements to Items
SSA System Safety Implementation Assessment System Implementation
Certification
Figure 3.4: System Engineering Process and Safety compliant with ARP-4754A
At Aircraft /System levels, a Functional Hazard At Aircraft / Systems levels as well, Preliminary Analysis (FHA) is primarily performed. The Safety Assessments are elaborated (PASA and process enables the identification of potential PSSA). PSSA is about determining how failures functional failures (of Aircraft and System could cause the Failure Conditions of the above Functions) and classifies failure conditions FHA. PSSA establishes the system or item based on the identified effects.
Methodology Handbook 3 - 18 SCADE System with ARP-4754A Objectives
safety requirements and provides preliminary CCA relies on all Safety Assessment processes. indication that the system architectures can meet In particular, a Common Mode Analysis is those safety requirements. performed. It verifies that all failures identified by the SSA are independent from each other in It is at this level that protective strategies can be the System architecture under evaluation. incorporated in the development process, such as: partitioning, redundancy, built-in tests, monitoring, independence, etc. 3.3.2 Development Assurance Level The System Safety Assessment (SSA) collects, Assignment analyzes, and documents the verification artifacts that demonstrate the system, as This is the process of assigning a Functional implemented, meets the safety requirements Development Assurance Level (FDAL) at established by the PSSA. Aircraft/System level, and consequently Fault Tree Analysis (FTA: deductive top-down attributing an Item Development Assurance failure condition analysis) and Failure Mode end Level (IDAL) to each item that constitutes the Effect Analysis (FMEA: inductive reviewing of Aircraft Function. items and systems to identify failure modes, and The table below shows the DAL assignment their causes and effects) are implemented at this levels that must be performed for each function stage. in the aircraft. Common Cause Analysis (CCA) establishes and These assignments are creating the necessary verifies physical and functional separation and rigorous basis for the assurance process isolation and independence requirements applicable to the development of functions/ between systems and items, and verifies that systems/items. these requirements have been met. Table 3.1: DAL assignment levels by aircraft function
Top-level failure condition severity classification Associated top-level function FDAL assignment
Catastrophic A
Hazardous/Severe Major B
Major C
Minor D
No Safety Effect E
Methodology Handbook 3 - 19 SCADE System with ARP-4754A Objectives
• Certification requirements: they may be required to 3.3.3 Requirements Capture demonstrate compliance with airworthiness regulations
Requirements capture can be textual or 3.3.4 Requirements Validation graphical. “When graphical requirement capture is planned, the A validated requirement is good and complete, following topics should also be included: and correct. • Identify the use of models/modeling A good and complete requirement is: • Identify the intended tools and their usage during the development • Necessary: it is not a simple remark, redundancy of • Define modeling standards and libraries in order to establish requirements is avoided a common understanding of the use of models • Implementation-independent: it specifies the Models used to capture requirements and then directly “what”, not the “how” used to produce embedded code (Software or HDL) come • Clear: it is not ambiguous, meant to be with the scope of DO-178B/ED-12B and DO-254/ communicated ED-80, from the time that certification credit is to be • Thorough: no amplification is needed taken until the software or hardware is returned to the • Consistent: it is compliant with the applicable system processes for system verification.” [ARP-4754A] standards Requirements can be: • Achievable: it can be implemented by the designers • Traceable: it can be allocated to a higher level • Functional requirements: those that describe the requirement (i.e., to the stakeholders’ needs) desired functions of the system. They are • Verifiable: by inspection, analysis, demonstration, constrained by operation conditions, regulatory or test restrictions, and real life. • Customer requirements: those that drive variants of A correct requirement is a requirement that is the aircraft well understood and feasible. • Operational requirements: those that define the Among usual techniques, such as checklists, interface between the various crews and the aircraft traceability matrices, etc., the ARP-4754A (flight crew, maintenance crew, etc.) standard mentions that prototyping can be an • Safety requirements: they are coming from the appropriate means for validating requirements. Safety Assessment Process “Prototypes are models of the desired system that may be • Performance requirements: define how the hardware and/or software based, and may or may not functions of the system are providing good service development versions of the system. Prototypes permit • Installation requirements, maintenance users of a system to interact with a proposed model of the requirements, physical interface requirements
Methodology Handbook 3 - 20 SCADE System with ARP-4754A Objectives
system to uncover missing requirements, behaviors of the development process when requirements compliance system that should be prohibited, and potential problems substanciation is first desired. The traceability of the with user interaction.” [ARP-4754A] final proposed configuration to, that configuration baseline is a necessary element of demonstrating The requirement validation rigor (including development assurance.” [ARP-4754A] independence in the validation process) is driven by the determined FDAL (see tables in Configuration includes: Appendix A). • System and items requirements • Applicable certification data listed in Section 3.3.8 3.3.5 Implementation Verification • Tools and utilities • Any other data that contributes to define the The verification process confirms at system system or items level that the required functions have been correctly implemented, so that the requirements 3.3.7 Process Assurance have been satisfied, and ensures that the results of the safety analysis are still valid after the The Process Assurance verifies that the plans implementation. and standards are developed, verifies that the Verification method, techniques and data are development is performed in accordance with those described in the section 2.6 those plans, and establishes reports of these verifications. 3.3.6 Configuration Management
“Configuration management is both a system development and a certification activity. A configuration baseline should be established at the time in the system
Methodology Handbook 3 - 21 SCADE System with ARP-4754A Objectives
At item level, DO-178B/C or DO-254 are 3.3.8 Certification Coordination applicable.
This process starts with the Certification planning and has the objective to provide evidence that the aircraft, system, item satisfy airworthiness requirements. Table 3.2: List of certification data at system level
Certification Plan summary of the main subjects and plans to manage for certification
Configuration index table that identifies all the items and interfaces of the system
Development Plan identify the overall process that leads the system development
Design Description describe the operations and capabilities of the system
Validation Plan ensure that the specified requirements are sufficiently correct and complete
Verification Plan ensure that the requirements have been correctly and completely satisfied (including safety requirements)
Configuration Management Plan set up the method to manage the configuration of elements that make up the system and its items
Process Assurance Plan describe the means to verify that guidelines and procedures are correctly applied
Functional Hazard Assessment (FHA): described below (described in Section 3.3.1)
Preliminary Aircraft/System Safety Assessment (PASA/PSSA) (described in Section 3.3.1)
Aircraft / System Safety Assessment (ASA/SSA) (described in Section 3.3.1)
Common Cause Analysis (CCA) (described in Section 3.3.1)
Validation Data results of the Validation Plan
Verification Data results of the Verification Plan
Evidence of the Configuration Management results of the Configuration Management Plan
Evidence of the Process Assurance results of the Process Assurance Plan
Certification Summary / Compliance Report results of all the Certification Plan (summary of results of all plans)
Methodology Handbook 3 - 22 SCADE System with ARP-4754A Objectives
4. SCADE Model-Based Systems Engineering
MBSE formalizes the practices of systems 4.1 Definition of MBSE engineering through the use of models and organizes models-centric activities instead of documents-centric activities. “Model-based systems engineering (MBSE) is the formalized application of modeling to support system As shown in Figure 4.1 below, the main risk requirements, design, analysis, verification and validation throughout the development process of a activities beginning in the conceptual design phase and product is the risk of inconsistencies, in continuing throughout development and later life cycle particular between the system that has been phases.” [INCOSE] specified by system engineers and the system that has been realized by the interdisciplinary “A model is an approximation, representation, or technical team. In addition, support processes, idealization of selected aspects of the structure, behavior, such as Safety Assessment, Process Assurance, operation, or other characteristics of a real-world process, and Certification have impacts throughout the concept, or system.” [IEEE 610.12-1990], i.e., an development process: addition of iterations and abstraction. increase of risks. “A model usually offers different views in order to serve different purposes. A view is a representation of a system from the perspective of related concerns or issues.” [IEEE 1471-2000].
Product System System PRODUCT Requirements Definition Integration
Development Process
Safety Assessment
Process assurance Configuration management
Certification Verification
Validation
Figure 4.1: Problem of consistency along the development process
Methodology Handbook 4 - 23 SCADE System with ARP-4754A Objectives
Most of the early information that governs the • Enable early identification of requirements issues system development can be collected into and validate the correctness of the requirements models and tables that can be shared among • Improve the allocation of requirements to items teams, encouraging cooperation over various • Establish rigorous requirements traceability, technical disciplines. facilitating early verification of requirements Model-based approaches are made for completeness communication, integration of changes, and safe • Speed up safe impact analysis of requirements management of key artifacts all along the changes systems engineering life cycle. Ensure integrity and reliable communication: Model-Based Systems Engineering improves • Create a single reference point that aggregates views quality and productivity, ensures systems and key data of the project engineering artifact integrity throughout the • Enable early design verification system development life cycle and, finally, • Auto-generate documentation optimizes the management of the development, Optimize Systems Engineering management reducing risks and facilitating decision making activities: (Figure 4.2). • Facilitate the reuse of existing valid models Improve quality and productivity: • Enable optimized iterations and valuable • Enable through simulation early discovering of increments operations and requirements • Allow early problem solving activities • Improve cost estimates
Methodology Handbook 4 - 24 SCADE System with ARP-4754A Objectives
System Requirements System Analysis Validation
System Functional System Verification Decomposition
System Architecture System Integration Definition
Detailed Design, Implementation & Optimization
Figure 4.2: Driven by models
Utilizing a Model-Based Systems Engineering interfaces. From the primary architecture model approach is even more beneficial. that directs the MBSE approach, SCADE System initiates the management and the export Systems Engineers recognize that elaborating of key data for the ICDs. and maintaining the Interface Control Documentation (ICD) is such an important and Another key advantage of MBSE is simulation. difficult task that it is a cost driver of the whole Simulation is much more than animating a system development process. The successful model. Simulation is a very efficient means for integration of components into a system early validation of concepts, and securing and depends on an early dependable ICD. optimizing the further development of In the MBSE approach, integrating views from “physical” components. different disciplines into models naturally forces We introduce the Simulation Driven Product focus on the system and components Development™ concept (SDPD) in the boundaries. In this chapter, we will present the following section. SCADE System tool and, more specifically, how SCADE System supports this focus on
Methodology Handbook 4 - 25 SCADE System with ARP-4754A Objectives
users’ needs, to validate system requirements, 4.2 Simulation Driven Product and to explore architecture opportunities before Development detailed components design. ENGINEERING GROUPS: “Modeling, simulation, and prototyping used during High-fidelity 3D Simulation practices are architecture design can significantly reduce the risk of implemented to obtain design adjustment data failure in the finished system […]. These techniques and to tune optimization factors before enable the development of complex and costly enabling hardware and electronics physical components systems. Systems engineers use modeling and simulation are designed. on large complex projects to manage the risk of failure to Model-Based Software Development best meet system mission and performance requirements.” practices specifically include simulation and [INCOSE] code generation. It means that the model is Organizations are still facing late design failures considered here both as an executable spec and when they heavily rely on physical integration to as executable code, which is a paramount verify up to system requirements. optimized process. On the opposite, relying on the appropriate INTEGRATION AND VERIFICATION & VALIDATION modeling and simulation techniques at each GROUPS: stage of the development life cycle allows Various Co-Simulation practices are validation of design decisions assigned to a implemented in order to verify a component in given stage before going to the next. a high-fidelity simulation environment prior to its integration into the system. As illustrated in Figure 4.3, Systems Architects, Engineering Groups, and Integration and V&V • 0D / 3D Co-simulation Groups are all requiring appropriate Modeling • Reduced Order Modeling (ROM) and Simulation solutions. • Model-in-the-Loop / Software-in-the-Loop / Hardware-in-the-Loop (MIL / SIL / HIL) SYSTEMS ARCHITECTS: Functional Simulation and 0D-Simulation are used to verify the feasibility of concepts, to evaluate operations, to aid the understanding of
Methodology Handbook 4 - 26 SCADE System with ARP-4754A Objectives
Integration and V&V Systems Best Practices Architects Virtual: • Virtual system integration & Requirements Management simulation and Functional Design • 0D – 3D co-simulation Best Practices • Reduced order modeling Physical: • Requirements analysis • Component Hardware testing • Requirements traceability • Calibration • Variant management Mixed: • Operational and usage analysis • SiL • Functional decomposition • HiL • Functional simulation • TiTiLL • Architectural design & selection Validation • Rapid prototyping • Physical system simulation (0D plant models) Groups
Engineering Detailed Design and Optimization Groups Best Practices Hardware Design Electronics Design Software Design • CAD • ECAD • Model-based controls design • Single physics • EDA • Model-based display design • Multiphysics • Circuit analysis • Automatic code generation • Optimization • 3D physics and certification • Multiphysics • Software configuration • Optimization management
Figure 4.3: Engineering practices and owners
Figure 4.4 below shows the positioning of SCADE System, together with SCADE ANSYS and Esterel Technologies tools suites LifeCycle Requirements Management Gateway, that span the entire range of physics, electronics, SCADE LifeCycle Rapid Prototyper, and and software so users can assess how their ANSYS Simplorer are the tools that implement design will behave in the real world and can SDPD at the early stages of the Model-Based verify their actual design in a high-fidelity virtual Systems Engineering process: world. • SCADE System is a systems modeling tool that was Modeling and Simulation foster “what-if developed specifically for modeling functional thinking” and exploration of design alternatives decomposition as well as systems architecture with for optimal solutions at each stage of the high dependability requirements managed using product development life cycle. SCADE LifeCycle Requirements Management Gateway, and providing full support of industrial ANSYS calls this approach: Simulation Driven systems engineering processes, such as ARP 4754A, Product Development (SDPD). ISO 26262 and EN 50126.
Methodology Handbook 4 - 27 SCADE System with ARP-4754A Objectives
• SCADE LifeCycle Rapid Prototyper enables fast • ANSYS Maxwell allows for analyzing modeling of human machine interfaces, thus electromechanical devices while ANSY HFSS can facilitates the elicitation of the system operations. simulate full-wave electromagnetic fields. • ANSYS Simplorer, utilizing multi-domain 0D • ANSYS Fluent gives the capability to model fluid simulation techniques, enables analysis of many dynamics including turbulences and heat transfers. aspects of systems, from electronic components to • Apache Design Solutions enable engineers to electromechanical components and mechatronics. design and simulate low-power high-performance Prior to implementation, modeling of integrated circuits. mechatronics components provides the ability • SCADE Suite and SCADE Display enable to simulate and analyze inner structures and engineers to model, simulate, and generate certified dynamics, as well as impact of deformations, code for embedded software, respectively stresses, fluids, thermal flows, and high- and embedded control software and human machine low-frequency electromagnetic: interfaces. While physical implementations and • ANSYS Mechanical offers simulation solutions for the analysis of linear and nonlinear structures, while verifications of electronic and hardware simulation of motion and stability of mechanical components are processed, their initial 0D and/ systems is handled by ANSYS Rigid Body or 3D models can be updated accordingly in Dynamics add-on. order to allow virtual simulation verifying late design choices.
System Requirements System Analysis Validation
System Functional System Verification Decomposition
System Architecture System Integration Definition SimplorerSi l
SiSimplorer l FluentFl t HFSS
Detailed Design, Implementation MaxwellMll & Optimization Apache MechanicsMechanic Solutions Figure 4.4: ANSYS / Esterel Technologies Systems Engineering solution map
Methodology Handbook 4 - 28 SCADE System with ARP-4754A Objectives
ANSYS Simplorer uses the IEEE standardized from SCADE Suite and SCADE Display prior language VHDL-AMS to develop plant models, to their integration with the physical as well as the capability to integrate Reduced components. Thus, Integration, which is usually Order Models from 3D physics based solvers a tense and hazardous phase, can be very for higher fidelity. These plant models can be progressive (Figure 4.5 below). used in verifying software applications generated
Control
[…] s w itch (SSM_SM1_dispatch_sel)) { c ase SSM_SM1_Locked__ABC_N : outC-- > foreground = white_ABC_N;; outC-- > background = green_ABC_N;; if (inC-- > Unloc k)) { outC-- >M_ pre_ = SSM_SM1_Preselected__ABC_N;ABC_ N ; } e lse { outC-- >M_ pre_ = SSM_SM1_Locked__ABC_N;N; } b reak; c ase SSM_SM1_WaitUnlock__ABC_N : outC-- > foreground = black_ABC_N;; outC-- > background = grey_ABC_N;; if (inC-- > Unloc k)) { outC-- >M_ pre_ = SSM_SM1_Unselected__ABC_N;ABC_N; } e lse { outC-- >M_ pre_ = SSM_SM1_WaitUnlock__ABC_N;ABC_N; } b reak; […]
HMI
Mechanical
0 R1 R2 R3 H01 C1 I7 Qcell1 Temp_block_1 C2 C3 Qcell2 Temp_block_2 E1 CONST Qcell3 Temp_block_3 Qcell4 Temp_block_4 0 Qcell5 Temp_block_5 R5 R6 R7 H02 Qcell6 Temp_block_6 C4 I8 E2 Tambi en C5 C6 RLoad CONST
0 R9 R10 R11 H03 350.00 C7 I9 C8 C9 E3 CONST 340.00
0 R13 R14 R15 H04 330.00 C10 I10 C11 C12 E4 Y1 [kel] CONST 320.00 Curv e Inf o U1.Temp_block_1 Electromechanical TR 0 U1.Temp_block_3 R17 310.00 TR R18 R19 H05 U1.Temp_block_5 C13 I11 TR C14 C15 Fluidic E5 CONST 300.00 0.00 2000.00 4000.00 6000.00 8000.00 Time [s]
Figure 4.5: Virtual system integration and V&V with ANSYS tools
The following section is handling the major In addition, Appendix D briefly describes features of SCADE System, which is at the SCADE Suite, SCADE Display, SCADE origin of the SDPD approach, like an architect LifeCycle, and ANSYS Simplorer. is at the origin of a construction project.
Methodology Handbook 4 - 29 SCADE System with ARP-4754A Objectives
4.3 SCADE System Features Overview
SCADE System is a system design tool suite for modeling safety-critical and mission-critical systems that is based on the SysML and Eclipse standards.
Figure 4.6: Designing with SCADE System
SCADE System features structural system descriptions. It allows, as well, systems engineers modeling, data dictionary, allocation tables, and to safely manage large amount of data related to architecture verification. naming, interfaces, and all artifacts that should be shared among the whole team. It allows critical systems designers to reduce duplication of efforts and to avoid Figure 4.6 shows the SCADE System Graphical inconsistencies between system architectural User Interface. descriptions and software/hardware/mechanical
Methodology Handbook 4 - 30 SCADE System with ARP-4754A Objectives
4.3.1 Model and Package
In SCADE System, a model is a graphically represented tree of packages of blocks that constitutes a system (Figure 4.7 below). The model gathers: • views of interconnected blocks (typically used to define functional view and architectural view) • the data dictionaries (data dictionaries are gathering additional data, for example refining information on the interfaces of the blocks) • the allocation tables (allocation tables are expressing the relationship between blocks or data) • the Libraries Packages are structuring the different views. Figure 4.7: Model and package in SCADE System
Methodology Handbook 4 - 31 SCADE System with ARP-4754A Objectives
block. Connectors connect the different blocks 4.3.2 Block Diagram through the ports. Blocks, ports, and connectors enable the representation of functional breakdown of the system, as well as its A Block Diagram (Figure 4.8 below) is a basic architectural construction. graphical construct of the model. A block has ports. Ports are input or/and output gates of the
Figure 4.8: Block Diagram in SCADE System
Methodology Handbook 4 - 32 SCADE System with ARP-4754A Objectives
For example, functional blocks can be allocated 4.3.3 Allocation Tables to component architectural blocks, and same for the corresponding interfaces (Ports). Using simple drag & drop actions, Allocation Tables (Figure 4.9 below) link objects of a package to objects of another package.
Figure 4.9: Allocation tables in SCADE System
Methodology Handbook 4 - 33 SCADE System with ARP-4754A Objectives
For any SCADE System object, the list of objects it is allocated to and the list of objects allocated to it ("Allocated from") can also be displayed and edited from the object Properties view.
Figure 4.10: Allocation in Properties
Methodology Handbook 4 - 34 SCADE System with ARP-4754A Objectives
The support of data dictionaries in SCADE 4.3.4 Data Dictionary System features: • Import and export of data dictionaries (copy/paste Tables of data are usual means used by systems from/to Excel spreadsheets) engineers to represent systems artifacts. In • Link data with the functional and architecture particular, the definition of interfaces in ICDs models necessitates a large amount of data to be • Data management is benefiting from the whole established, distributed among teams, and SCADE System engineering capabilities: graphical maintained. views, traceability, diff, report, automated verifications, etc. Data created in a SCADE System project can be particularized using predefined properties and As shown in Figure 4.11 below: structured annotations. • SCADE System Data Dictionary is implemented as a block viewed in the model tree These properties and annotations can be viewed in tables. • Data are gathered from structured information via the annotation mechanism The tables, as a whole, make up the Data • Data properties can be shown and edited in Dictionary, in SCADE System. customizable Tables
Figure 4.11: Data dictionary in SCADE System
Methodology Handbook 4 - 35 SCADE System with ARP-4754A Objectives
As shown in Figure 4.12 below, data allocations can also be graphically displayed in diagrams.
Figure 4.12: Allocation of additional data to connections between blocks
Checks are processed with a set of selectable 4.3.5 Model Static Checking rules (predefined rules or user-defined rules). The selection is defined in configurations allowing for distinct checks. These checks can SCADE System Checker is a tool which checks target specific parts of the model. For example, models for consistency and for other project- some checks apply to the Functional dependent constraints. Decomposition only and some other checks apply to the Architecture Definition only.
Figure 4.13: List of rules available for static checking
Methodology Handbook 4 - 36 SCADE System with ARP-4754A Objectives
SCADE System Checker reports as shown in Figure 4.14.
Figure 4.14: SCADE System Checker
Methodology Handbook 4 - 37 SCADE System with ARP-4754A Objectives
4.3.6 Traceability Management
SCADE LifeCycle Requirements Management Gateway is accessible via SCADE System in order, for example, to allocate requirements to functions and component architectural blocks (Figure 4.15).
Figure 4.15: Traceability management in SCADE System
Methodology Handbook 4 - 38 SCADE System with ARP-4754A Objectives
4.3.7 Model Documentation Generation
SCADE LifeCycle Reporter is accessible from SCADE System to generate complete documentation of the model (Figure 4.16).
Figure 4.16: Complete documentation generation in SCADE System
Methodology Handbook 4 - 39 SCADE System with ARP-4754A Objectives
SCADE System allows for transforming a block 4.3.8 System-Software interface into inputs/outputs of the Synchronization corresponding software operator to be implemented in SCADE Suite. Each block of a SCADE System model can be When modifying either side, it is possible to assigned to a specific implementation. resynchronize the corresponding tagged SCADE System blocks with the SCADE Suite For example, blocks that represent a piece of operators. (Figure 4.17). software can be tagged as being implemented using SCADE Suite.
Figure 4.17: Synchronization with SCADE Suite
Methodology Handbook 4 - 40 SCADE System with ARP-4754A Objectives
5. SCADE Model-Based Systems Engineering Process
The two following activities are dedicated to the 5.1 SCADE Model-Based Systems implementation of Items: Engineering V-Cycle • Models of the Items are elaborated and simulated (can be: software models, hardware electronics 0D models, hardware mechanics 3D models, etc.) Figure 5.1 below represents the Model-Based • Then, the Items are implemented according to their Systems Engineering (MBSE) V-Cycle. This V- respective certification standard; for example: cycle is compliant with ARP-4754A and • Software items compliant with the DO-178B/ demonstrates the SDPD approach. In this C standard SCADE MBSE V-cycle, one can distinguish • Electronic hardware items compliant with the twelve activities. DO-254 standard Three activities are supporting the process of It is important to notice that, when developed establishing the System Requirements: with SCADE Suite or SCADE Display, models • Analysis of the Requirements of the software items also embody the • Decomposition of the Functions implementations: SCADE Suite and SCADE Display feature DO-178B/C qualified Code • Validation of the Requirements Generators that make the generated code a Four activities are assigned to the establishment correct implementation of the model behavior. of the Architecture artifacts: The last three activities are about: • Definition of the Architecture • Integrating • Validation of the Architecture • Verifying • Allocation of Functions to Items • Validating both the Items and the built System • Allocation of Requirements to Items
Methodology Handbook 5 - 41 SCADE System with ARP-4754A Objectives
System Level
Requirements Analysis System Validation
Requirements Validation
Functional Decomposition System Verification
Architecture Virtual and Physical Validation
Architecture Definition Integration
Allocation of Functions to Items Virtual and Physical
Allocation of Requirements to Items
Items Level Simulation-Driven Items Modeling Product and Simulation Development
Items Implementation and Verification
DO-178C, DO-254,…
Figure 5.1: ARP-4754A compliant SCADE MBSE V-Cycle (System Level)
The purpose of Requirements Analysis is to 5.2 Requirements Analysis refine users’ needs and objectives, define expected performances, and identify constraints and standards that are limiting the solutions. Since the purpose of Systems Engineering process is to transform Requirements into Achieving the goal of the Requirements Designs, Requirements are the primary and the Analysis, while all is coming from dissimilar most important focus of the Systems Engineers. ideas and diverse needs, is not an easy task. Requirements Analysis is the act of converting Process and iterations are tightly required. the stakeholders’ needs into a set of validated Requirements that will be managed with all the interdisciplinary teams.
Methodology Handbook 5 - 42 SCADE System with ARP-4754A Objectives
Requirements Analysis is conducted iteratively with Functional Decomposition, Architectural 5.2.1 Requirements Elicitation Design and Safety Analysis, and benefits from them. Requirements Elicitation is a complex process However, the first goal of the process is to that basically intends to go from a collection of establish an initial set of System Requirements, incomplete, unstructured, and possibly called Elicitation of the Requirements, on inconsistent needs to an organized knowledge which, and from which, the other activities are base, as illustrated in Figure 5.2 below. performed.
Collect Analyze Control & Refine • Objectives & Business Goals • Problem to solve With.. • Background & Organizational • Domain of Application • Constraints Situation • Prioritization & Categorization • Existing Systems • Stakeholders needs • Technology & Domain Knowledge
Initial Set of Requirements
Figure 5.2: Requirements elicitation process
One primary and very important The stakeholders give their “needs” to the accomplishment consists in identifying the project: complete range of stakeholders: • Users: preliminary requirements (a.k.a., parent • Who has an interest in the system throughout its requirements), etc. entire life cycle? • Operators: use cases, etc. • Have all the stakeholders expressed their needs? • Decision-makers: business case, budgets, schedule, The stakeholders of a project developing a given organization, reuse policy, etc. system are those that have a legitimate interest • Regulatory bodies: safety case, industry standards, in this system. They are: applicable laws, etc. • Users (needing services delivered by the system) Other “inputs” should be considered: • Operators (interacting with the system) • Procedures, standards, guidelines that the project • Decision-makers (giving system objectives) should conform to • Regulatory bodies (constraining the system) • State-of the-art technology, technology breakthroughs,
Methodology Handbook 5 - 43 SCADE System with ARP-4754A Objectives
Once all of the previous aspects are considered, “Every system makes specific assumptions about the it is possible to establish the preliminary environment in which it will operate. Some of these requirements: what the system must accomplish assumptions are nothing more than the types, ranges, and and how well? units of the inputs it will accept and the outputs it will produce. Often, correct behavior of the system is An initial classification of the System dependent on more complex assumptions about its Requirements is made according to: environment. These are actually requirements levied by • Functional requirements the system on its environment. Identification of a system’s • Safety requirements environmental assumptions is essential for maintenance • Certification requirements and to enable reuse. Failure to identify the environmental • Constraints requirements assumptions and the subsequent misuse of the system is a common cause of system failure.” [DOT/FAA/AR- • Derived requirements 08/32] Functional Requirements are representing the services that the system should provide. They Derived requirements are those that are added encompass the performance requirements and during and by the Systems Engineering process. the interface requirements. These requirements do not change the requirements coming from stakeholders’ needs. Safety requirements are driving the requirements They usually refer to technology, design, for safety prevention such as redundancies or methods, and tools requisites. physical partitioning. Another primary goal of this initial classification The ARP-4754 process is meant to structure is to extract the leading requirements which are these inputs into the Requirements Analysis the subject of the next mini-step: Identification process. of the operations (generally speaking, these The impact of Certification requirements is leading requirements are mostly functional focused on functional and architectural requirements, but other breakthrough dissimilarities of designs. requirements can be considered for the identification of the Operations). Constraint requirements (a.k.a., Assumptions) are dealing with functional and architectural variants, maintenance, built-in-testing, 5.2.2 Operational Analysis installation, resource allocation, boundaries conditions, environmental assumptions, reuse Operational Analysis is a Requirement constraints, manufacturing conditions. Elicitation method, especially performed (but For systems that are mostly implemented by not only) when the system is developed from a software components, the FAA states: concept (i.e., “from scratch”).
Methodology Handbook 5 - 44 SCADE System with ARP-4754A Objectives
This activity is also known as Concept Analysis A CONOPS generally evolves from a concept and is a or Concept of Operations (CONOPS). description of how a set of capabilities may be employed to achieve desired objectives or end state.” (Source: “A concept of operations is a document describing the Wikipedia) characteristics of a proposed system from the viewpoint of an individual who will use that system. It is used to Operational Analysis primarily describes the communicate the quantitative and qualitative system necessary elements of the context and the characteristics to all stakeholders. CONOPS are widely system as illustrated in Figure 5.3 below [ANSI/ used in the military, governmental services and other AIAA]. fields.
Figure 5.3: Operational Analysis
This activity starts with the identification of the environment that the system will affect. For example, System boundary. monitored values might be the actual altitude of an aircraft and its airspeed, while controlled variables might For systems that are mostly implemented by be the position of a control surface, such as an aileron or software components the FAA recommends the the displayed value of the altitude on the primary flight following practice: display.” [DOT/FAA/AR-08/32] “Recommended Practice 2.2.1: Define the system To help identify System Context, including the boundary early in the requirements engineering process by users and operators of the system, SCADE identifying a preliminary set of monitored and controlled System offers the capability to model a block variables. […] The monitored variables represent diagram with Actors. This top-level model is quantities in the environment that the system responds to, while the controlled variables represent quantities in the
Methodology Handbook 5 - 45 SCADE System with ARP-4754A Objectives
structuring the placing of the system in its environment where it interacts with its users and other actors (Figure 5.4)
Figure 5.4: Top-level model in SCADE System
Relying on Context Analysis, Concept Analysis Graphical techniques and tools can be used to then describes the missions (a.k.a., scenarios of best describe the users’ perspectives and use) of the system in its operational operations: story boards, state diagrams, use environment as an integrated view that ensures cases or sequence and activity charts, and all the subsequent requirements are identified Prototyping. and are coherent (individual functions must meet their specification and the whole must meet the users’ needs).
Methodology Handbook 5 - 46 SCADE System with ARP-4754A Objectives
Figure 5.5 below shows a Fighter Mission 5.2.3 Prototyping the Operations System using a Radar and an IFF (Identification Friend or Foe). On the bottom left, a panel of graphical widgets that allows creating scenarios. As far as aircraft systems made of electronic On the top right, the system information hardware and software are concerned, displayed to the pilot. prototyping means Virtual Prototyping, which is a combination of Modeling and Simulation techniques.
Important Note Prototyping is both an Elicitation means and a Validation means (see Section 5.3). Here, it is about prototyping the operations, while, for validation purpose, the functions are prototyped. Operation is also known as Mission or Scenario of Use.
Figure 5.5: Prototyping operations
Methodology Handbook 5 - 47 SCADE System with ARP-4754A Objectives
SCADE LifeCycle Rapid Prototyper includes a Using SCADE LifeCycle Requirements wide collection of widgets. It enables the Management Gateway, it is possible to declare construction of a virtual prototype, like the SCADE System model elements as above Fighter Mission System. requirements by means of dedicated comments.
5.2.4 A Focus on Derived 5.3 Functional Decomposition Requirements
The objective of this process is two-fold: “At each phase of the development activity, decisions are made as to how particular requirements or groups of • Define elementary functions that are able to be allocated to items requirements are to be met. The consequences of these design choices become requirements for the next phase of • Define a functional model of the system that is able the development. Since these requirements result from the to contribute to the validation of the requirements design process itself, they may not be uniquely related to a It allows focusing on what has to be achieved, higher-level requirement and are referred to as derived not how. When doing so, more solutions may requirements.” [ARP-4754A] be systematically explored (Figure below). Architecture artifacts are coming from decisions made during the System design process. The Functional Decomposition Architectural Definitions Architecture requirements are passed to the • Takeoff and Land teams in charge of the next phase: the • Sense Position and Velocity • Navigate Implementation phase. • Produce Horizontal Thrust • Produce Vertical Lift This practice, i.e., creating Derived Requirements, is somehow banished at Item development level, when governed, for example, by DO-178B/C objectives: derived requirements can be identified during the process, but the usual practice is to create additional high-level requirements that allow Figure 5.6: Functional Decomposition versus canceling them. Architectural Definitions As a consequence, to avoid confusion, one calls The purpose of the process is to model a “Requirements from System Design”, the breakdown of the functions from the actual set Requirements that are made when decomposing of requirements. Interfaces are identified and the functions with SCADE System and that are modeled as well. Each function is expressed as better expressed by a model than by a text. an action, starting with a verb, for example: “Control the flight”.
Methodology Handbook 5 - 48 SCADE System with ARP-4754A Objectives
The decomposition of a top-level function stops Decomposition, Architecture Design, and when the actual “leaf” function is supposed to Allocation of Functions to Items are fit the architectural definition (it means this completed). supposition is confirmed only when Functional
Figure 5.7: Functional decomposition of an aircraft system
Each Function must be verified regarding: • Uniqueness • Naming conventions • Usefulness (within the functional decomposition) • Description and attributes SCADE System Checker can check the rules that can be automated.
Methodology Handbook 5 - 49 SCADE System with ARP-4754A Objectives
Figure 5.8: SCADE System Checker run on an aircraft system model
The overall Functional Decomposition must be • Readability checked as well: • Balance between level of abstraction and level of • Consistency granularity • Requirements Coverage (Exhaustiveness)
Methodology Handbook 5 - 50 SCADE System with ARP-4754A Objectives
Figure 5.9: Requirements Management Gateway coverage measurement
• Validation matrix (or other adequate means) to 5.4 Requirements Validation track the status of the Validation process • Validation summary that gives status of the validation plan and results The drivers of this activity are: completeness and correctness. 5.4.1 Completeness Checks Usual objectives and means for requirements validation include: The completeness of a set of requirements is a • Validation plan that defines the methods, tools, and demonstration that should be ensured by schedule implemented to validate the requirements independent engineering peer review, as it is not • Rigor, determined by the FDAL an easy task to implement automations or • The various checklists defined for validation tooling to support this activity. through peer review
Methodology Handbook 5 - 51 SCADE System with ARP-4754A Objectives
Checklist is the usual basis for executing such • Are all types of requirements represented: Safety, activity, including, but not limited to, the Regulatory, Company standards? following list of questions (complete list is in • Are all interfaces to other systems, actors, and section 5.4.4 of the ARP-4754 standard): processes embodied? • Are all Parent Requirements covered? • For a defined use, is the prohibited use defined as well? • Are all Functions of the Function Decomposition traced back to Requirements? • Are Assumptions clearly defined? • Are all scenarios of use (Operations) and of • Etc. maintenance represented?
1. Plan 2. Inspect 4. Complete
3. Rework
Figure 5.10: Engineering peer review process
• On the opposite, does it conflict with others? 5.4.2 Correctness Checks • Is it feasible to serve it? • Is it verifiable? (Testable?) For Correctness Checks, engineering peer • If it is a derived requirement: is it justified? review is an appropriate means as well. • Is it necessary? In addition, modeling and simulation can be used to represent the actual understanding of 5.4.3 Prototyping Functions for the system functions that are traced to the Correctness Check source requirements. The checklist is including, but not limited to, the Prototyping is recognized by the ARP-4754A following list of questions (complete list is in standard as an appropriate means to section 5.4.3 of the ARP-4754 standard): demonstrate that a requirement is correct. • Is the requirement unambiguous? SCADE Suite is used to prototype: • Is it clearly stated as a requirement? • Algorithms and control laws • Is it not redundant? • Control logic and behaviors
Methodology Handbook 5 - 52 SCADE System with ARP-4754A Objectives
SCADE LifeCycle Rapid Prototyper is used to prototype Human-Machine interfaces. 5.4.4 Focus on Assumptions Validation
Assumptions are stated at the same time as requirements. However, Assumptions are statements that cannot be provable while the system is being developed. Thus, Validation of Assumptions consists of: • Ensuring that they are explicitly specified as Assumptions and are correctly circulated as is • Verifying they are “reasonably categorized as Assumptions” • Justifying all of them The point is about the term: “reasonably categorized Figure 5.11: Prototyping of functions as Assumptions”. Thus, the usual Assumptions that can be met and accepted are listed below: ANSYS Simplorer capabilities are used to model and simulate the physical environment in order • Operational Assumptions (also called: Environmental Assumptions): they are related to air to perform closed loop simulation. traffic, operational procedures, passengers, etc. Co-simulation of these 0D-Simulation tools • Design Assumptions related to the crew interface, enables the prototyping and simulation of the to interface with other systems, and associated with functions of the system. A balance between reliability topics: realistic conditions of simulation and time to • Example of crew interface assumption: crew simulate is made. response time to a message displayed by the system At the end, the correctness of the requirements that are traced to the simulated functions is • Example of system interface assumption: validated in the approximated context of the probability of bus errors simulation. • Example of reliability topic that triggers assumption: frequency of maintenance tasks • Serviceability Assumptions and Installation Assumptions that can be validated against the procedure standards assigned to the project.
Methodology Handbook 5 - 53 SCADE System with ARP-4754A Objectives
2 or as a level of the architecture definition 5.5 Architecture Definition from which all the physical solutions are established
“The organization produced through functional analysis In the second case, a level of traceability linking is a logical architecture that may not take into account is added. additional constraints, such as the need to satisfy system In all cases, it is recommended to keep all safety requirements, integrate with legacy systems, or to architecture alternatives in configuration in meet implementation constraints imposed by a particular order: platform. This practice describes an iterative process that • starts from the previously developed functional to record how the decision is made architecture and leads to an architecture that addresses • to be able to retrieve the Logical Architecture these concerns. This architecture is then used as the In this chapter, we consider Logical framework for organizing the detailed requirements.” Architecture at the same level Physical [DOT/FAA/AR-08/32] Architectures are considered. Architecture definition conveys how to build the system and with what. Thus, at the end of the 5.5.1 Architecture Modeling process, the requirements for the physical artifacts are defined; this is called Physical Objective of the process Architecture. • Identify items But, for complex systems and/or when trade- • Identify interfaces between items off between several architecture opportunities is both necessary and dense, it is sometimes better • Organize items breakdown to define how to build the system prior to with Types of item that are considered: what to build it. It is called Logical Architecture. • Software items Doing like this, the organization of the items of • Hardware items (electronics that carry software or the system is defined apart from the physical operate logical function) solutions to be established, including reuse and • Electrical items (Actuator, electrical device, motor) other constraints. • Mechanical items (gear box, torque shaft) In the SCADE MBSE approach, it is possible to • Chemical items (battery) consider the Logical Architecture: • Hydraulic items (pump, tank, duct, turbo) 1 as the first of the architecture solutions (at Types of interface between items: the same level of the others, and from which • Software to Software the others are derived) • Software to Hardware
Methodology Handbook 5 - 54 SCADE System with ARP-4754A Objectives
• Hardware to Hardware • Attributes related to the physical aspects of the • Hardware to Mechanics item, such as: weight, volume, boundaries, resources (electrical, hydraulic, pneumatic power, • Mechanics to Mechanics etc.) At this stage, a “Make or Buy” policy is leading • Attributes associated with the operational aspects the Systems Engineering decision making: of the item: tasks assigned to the item, safety existing company’s solutions and/or COTS specification, complexity, Technology Readiness solutions may be considered. Level (TRL), etc. The constraint requirements govern the • Performance parameters (useful for future trade-off implementation solutions: the physical taking into account stakeholders’ criteria) architecture is led by the “Design to Cost” • Attributes attached to the development process of policy and should respect the performance and the item: dependencies between items (some items safety constraint requirements. must be developed before others to enable a correct development plan), cost of development, Items can be characterized using additional cost of product, development schedule, quality information. SCADE System Annotation articles, etc. capability allows extending the objects of the model with, for example, the following attributes or additional information:
Methodology Handbook 5 - 55 SCADE System with ARP-4754A Objectives
Figure 5.12: Architecture definition of the Fighter Mission system
contribute to the realization of any of these hazards. If 5.5.2 Relationship with Safety Analysis so, derived system design safety requirements are levied by the PSSA.” [DOT/FAA/AR-08/32] “For safety-critical systems, the process of modifying the Among other activities, Failure Mode and Effect functional architecture to accommodate implementation Analysis (FMEA) are an integral part of the constraints is often driven by the need to achieve the very Global Safety Analysis of the System. high levels of reliability dictated by the system safety FMEA Approach is an inductive step-by-step process. For commercial avionics systems, this process is approach that identifies all possible failures in a described in ARP 4761. One of the first steps of this design. Failure Mode defines the way in which process is the system Functional Hazard Assessment something can fail. Effect Analysis is about (FHA) that identifies the high-level system hazards. The reviewing the consequences of the failure. FHA is then used during the Preliminary System Safety Assessment (PSSA) to determine if the system could This analysis is performed on the preferred Architecture of Items that was defined.
Methodology Handbook 5 - 56 SCADE System with ARP-4754A Objectives
FMEA Process consists in calculating a Risk • Usefulness: Verify that no item is detached from Priority number for each Failure Mode that has the Product architecture, all ports are connected to significant Effect as shown in Figure 5.13. other ports or to actors. Check the whole actual Architecture to ensure In the MBSE context, local FMEA is performed the quality of the defined System architecture. for each functional block, then propagation to The following points are suggested to be the upper level of the architecture is examined. evaluated: • Readability: The Architecture must be 1. Detect a Failure understandable by all stakeholders. There must be Actions Mode and no ambiguity in the architecture description Check • Level of Abstraction: The architecture must show 2. 2. Risk Priority = Apply a Severity the right elements at the right place. This is good SxOxD Number S moment to collect innovative ideas for solutions
FMEA • Does the item support the function in the right way? • Could this be done differently? In case of problem, state it as functional analysis warning 4. 3. Apply a Apply a for future consideration Likelihood of Probability of Detection D Occurrence O • Level of granularity: at the same level of abstraction, the granularity of items should be Figure 5.13: Local FMEA at block level equivalent, in terms of item value and associated SCADE System’s graphical representation communication means. significantly facilitates FMEA within blocks as • Coverage: using SCADE System Allocation Tables well as the propagation to the whole system. (please see next section) check that the items of the Architecture Definition cover the functions of the Functional Decomposition. 5.6 Architecture Validation •Consistency of the whole architecture: • Is there redundancy of different parts of the Check each item and their communication architecture? means: • Are there contradictions or inconsistencies • Naming: Verify that the name/description of the within the architecture? Item is clear and is meaningful SYNTHESIS AND SELECTION OF THE ARCHITECTURE • Uniqueness: Verify that no other equivalent SOLUTION element (in terms of attributes & relationships) A trade-off review is required to compare exists within the same architecture candidate system architectures. The objective is to select the preferred solution, i.e., most
Methodology Handbook 5 - 57 SCADE System with ARP-4754A Objectives
adapted to the operational, functional, business, and organizational drivers coming from the 5.7 Allocations whole set of stakeholders.
Modeling and 0D-Simulation can be used to As shown in the figure below, there are multiple help select the preferred Architecture. allocations created along the SCADE MBSE For a given criterion (for example: power process. consumption, weight, temperature, etc.) a set of However, in the SCADE MBSE V-Cycle (Figure items can be abstracted/modeled according to 5.1), two allocation activities are pinpointed: the various architectures. Simulation results are compared. • Allocation of functions to items • Allocation of requirements to items
SCADE Requirements Management Gateway Requirements SCADE System / SCADE Suite Specification Synchronization SCADE System Allocation Tables
SCADE Suite Functional SCADE Display Decomposition
Architecture of Software Item SCADE System Items Implementation
Figure 5.14: Several types of allocations
Allocation of functions to items is highlighted Allocation of requirements to items is because it is the best method to verify that the highlighted as well because it is the major functional decomposition and the architecture outcome of the initial phases of the whole organization are satisfactorily completed and SCADE MBSE process. The main inputs of the that they match together. software process mentioned in the DO-178B standard are requirements allocated to software.
Methodology Handbook 5 - 58 SCADE System with ARP-4754A Objectives
SCADE LifeCycle Requirements Management 5.7.1 Allocation of Requirements to Gateway supports the tracing of links between Functions requirements and functions.
This allocation involves traceability links between requirements and functions.
Figure 5.15: Requirements Management Gateway links between requirements and functions
SCADE LifeCycle Requirements Management • What are the uncovered requirements Gateway analyzes the traceability information to • What is the impact of a requirement change elaborate and display results on: This allocation activity stops when all • How the requirements are covered requirements are covered by functions.
Methodology Handbook 5 - 59 SCADE System with ARP-4754A Objectives
Figure 5.16: Requirements Management Gateway coverage of requirements by functions
Figure 5.17: Requirements Management Gateway impact analysis between requirements and functions
Methodology Handbook 5 - 60 SCADE System with ARP-4754A Objectives
of a Logical Architecture definition and then to 5.7.2 Allocation of Functions to Items an ARINC 429 frame defined in a Physical Architecture. The allocation activity using SCADE System Best practices: Allocation Tables consists in “projecting” one • Allocation activity is driven by the question: which object of the functional decomposition package item is supporting this given function? to an object of the architecture definition • Except if replication is required for safety reason, package. each function is allocated to only one item; if a These objects are typically Blocks, Ports, and function is about to be allocated to more than one Data. item, it should mean that this function is realized several times for redundancy purposes. It is not a Objects are allocated: blocks that represent good practice to have a function that is jointly functions to blocks that represent item. realized several items; in that case the function must be further split up. Interfaces of these objects and data that describe these objects can be allocated as well. • On the other hand, an item can support several functions. For example, a Speed variable that is communicated by a function to another function can be allocated to a set of logical data
Figure 5.18: Allocation table of functions to items: an efficient way to manage functional decomposition
Methodology Handbook 5 - 61 SCADE System with ARP-4754A Objectives
requirements and system design decisions to the 5.7.3 Allocation of Requirements to implementations is to allocate requirements to Items items and finally to deliver the allocated requirements to every team in charge of item implementation. Once requirements are allocated to functions and functions to items, and 100 percent coverage is achieved, the last duty before giving
Figure 5.19: Requirements Management Gateway links between requirements and items
• Items (Blocks) definitions and naming 5.8 Dissemination of Interfaces • Inputs and Outputs and Data • Data that describe the Items
In addition to the requirements, the other design decisions made during early systems engineering activities must be dispatched in an organized way among:
Methodology Handbook 5 - 62 SCADE System with ARP-4754A Objectives
SCADE System provides a synchronization 5.8.1 System/Software feature between SCADE System model and Synchronization SCADE Suite software model that avoids duplication of efforts and error-prone redesign: The team in charge of developing a given • Synchronization of interfaces defined at system software item expects from the Systems level and refined at software level Engineering process: • Management of the incremental design thanks to the re-import feature: the System Model Evolution • The requirements allocated to the item directly impacts the relative software model without • The top-level architecture and interface, including clearing local changes done on this software model naming of the item
Figure 5.20: System – Software Synchronization: System Model in SCADE System
Methodology Handbook 5 - 63 SCADE System with ARP-4754A Objectives
description, the data format, the range of values it may 5.9 Data Dictionary Management assume, its location, and any protocols to follow when accessing it.
It is compulsory that System Engineers provide Recommended Practice 2.9.7: For each output the to the teams in charge of the implementations software must set, provide a description of anything the additional rationale or comments on why a software developer must know to access and correctly set requirement was established and/or why a its value. This may include an output description, the particular value or range was specified. data format, the range of values it may assume, its location, and any protocols." [DOT/FAA/AR-08/ For Software Items, the FAA recommends what 32] follows: Many data can be defined at SCADE System “Recommended Practice 2.9.1: For each input the model level. These data carry additional software must read, provide a description of anything the rationale, statements, ranges, etc. software developer must know to access and correctly interpret the input. This may include an input In SCADE System, such data can be created from several sources: properties, tables, etc.
Figure 5.21: Data Dictionary in SCADE System
Methodology Handbook 5 - 64 SCADE System with ARP-4754A Objectives
The processes related to requirements are: 5.10 ARP-475A A-1 Table: Sections • Aircraft and System Development Process and Related to Requirements Requirement Capture • Safety Assessment Process • Table A-1, Process Objectives, Outputs and Requirements Validation Process System Control Category, lists the objectives The table below provides the contributions of and expected outputs of the Systems the SCADE MBSE approach. Engineering processes.
Objectives SCADE Model-Based Section Output Comments Systems Engineering Nr. Description Solution
2.0 Aircraft and System Development Process and Requirements Capture
Note: requirements Aircraft-level functions, 4.1.4 List of Aircraft-level capture process Aircraft-level functions are functional requirements, functions objectives presented 2.1 4.2 high-level activities and are functional interfaces and Aircraft-level in section 5.3 are not necessarily associated 5.3 assumptions are defined requirements included in this with a single, physical system development process implementation. Not managed by the SCADE Aircraft functions are 4.1.5 System MBSE approach. 2.2 allocated to systems 4.3 Requirements
System requirements, SCADE System is supporting including assumptions and System the achievement of these 2.3 5.3 system interfaces are Requirements objectives: Functional defined decomposition using SCADE System combined with SCADE LifeCycle Requirements System derived Management Gateway and requirements (including 4.4 System SCADE LifeCycle Reporter 2.4 derived safety-related 5.3.1.4 Requirements allow the correct and requirements) are defined 5.3.2 complete establishment of and rationale explained system requirements.
SCADE System enables the establishment of the 4.1.6 architecture of items. System architecture is System Design 2.5 4.4 The top level System Design defined Description Description is automatically 5.8.4.4 generated from the SCADE System model using SCADE LifeCycle Reporter.
Methodology Handbook 5 - 65 SCADE System with ARP-4754A Objectives
Objectives SCADE Model-Based Section Output Comments Systems Engineering Nr. Description Solution
SCADE System allocation 4.1.7 tables together with SCADE System requirements are 4.5 LifeCycle Requirements 2.6 Item Requirements allocated to the items 4.6 Management Gateway enable 5.3 the allocation of requirements to every item.
ANSYS Simplorer allows for virtual integration of software items developed with SCADE Suite and SCADE Display and Reduced Order Models of Appropriate item, system other items within a model of 4.6.3 Verification 2.7 and aircraft integrations the aircraft environment Summary are performed 4.6.4 (MIL). The same tools used in conjunction with Hardware prototyping tools also allow to do a mix of physical and virtual integration (SIL, HIL).
3.0 Safety Assessment Process
5.1.1 The aircraft/system Aircraft FHA 3.1 functional hazard 5.2.3 System FHA assessment is performed 5.2.4
The preliminary aircraft 5.1.2 3.2 safety assessment is 5.2.3 PASA performed 5.2.4
5.1.2 The preliminary system 5.1.6 3.3 safety assessment is PSSA performed 5.2.3 5.2.4
Particular Risk Assessment
The common cause Common Mode 3.4 5.1.4 analyses are performed Analysis
Zonal Safety Analysis
The aircraft safety 5.1.3 3.5 ASA assessment is performed 5.1.6
Methodology Handbook 5 - 66 SCADE System with ARP-4754A Objectives
Objectives SCADE Model-Based Section Output Comments Systems Engineering Nr. Description Solution
The selected architecture of items and their interactions The system safety 5.1.3 3.6 SSA modeled in SCADE System is assessment is performed 5.1.6 given to the Safety team to perform safety analysis on it.
System, HW, SW Independence 5.3.2 requirements in functions, Requirements 3.7 5.2.3 systems and items are PASA 5.1.3 captured PSSA
4.0 Requirements Validation Process
Functional Decomposition model and Architecture model of the System elaborated using SCADE System are providing an organized formal basis to assess completeness and correctness of the set of requirements.
SCADE LifeCycle Rapid 5.4 Includes coordination Aircraft, system, item Prototyper together with 5.4.2c of interfaces between 4.1 requirements are Validation Results SCADE Suite, SCADE Display, systems and between complete and correct 5.4.3 and ANSYS Simplorer allow 5.4.4 items the prototyping of functions that enables the validation of the correctness of the requirements. SCADE LifeCycle Requirements Management Gateway and SCADE System allocation tables are supporting the validation of the completeness of the requirements.
Assumptions are justified 4.2 5.4.2d Validation Results and validated
5.3.1.4 Derived requirements are 4.3 5.3.2 Validation Results justified and validated 5.4.2
Requirements traceability is ensured with the use of Requirements are 5.4.3 4.4 Validation Results SCADE LifeCycle traceable 5.4.4 Requirements Management Gateway.
Methodology Handbook 5 - 67 SCADE System with ARP-4754A Objectives
Objectives SCADE Model-Based Section Output Comments Systems Engineering Nr. Description Solution
5.4.2e Validation Summary Validation compliance 5.4.2f 4.6 (including Validation substantiation is provided 5.4.8 Matrix) 5.4.7.4 3D models for mechanical items can be 5.11 Item Modeling developed using a large set of ANSYS Tools. 0D models for electronic hardware items can be Modeling, including Simulation, is recognized as elaborated with ANSYS Simplorer. the shortest path to item. 0D models of software items can be developed It enables rapid evaluation of design choices. It with SCADE Suite and SCADE Display. avoids hidden pitfalls. It helps rehearsing development strategies so that the implementation phase is significantly optimized.
Figure 5.22: 3D models and 0D models
Methodology Handbook 5 - 68 SCADE System with ARP-4754A Objectives
Figure 5.23: Simulation in Simplorer
While, many techniques are employed to SCADE Suite or SCADE Display are also the increase their fidelity to real behaviors, most of real software applications to be integrated as the models stay virtual, models made with physical items of the built system.
Methodology Handbook 5 - 69 SCADE System with ARP-4754A Objectives
Figure 5.24: Simulation of SCADE Display Application (UAV Ground Station Control)
They are all dependent on each other (see Figure 5.12 Item Implementation 3.1) and all objective-based (as summarized in the following tables):
Implementation of software and hardware • Table A-1 for ARP-4754A electronics are respectively driven by DO-178B • Tables A1 to A10 for DO-178B/C (or DO-178C), and DO-254 guidelines. • Table A-1 for DO-254 ARP-4754A, DO-178, and DO-254 are assurance-focused processes that establish that the development, from system design to item design, is conducted in a way that guarantees the aircraft safety.
Methodology Handbook 5 - 70 SCADE System with ARP-4754A Objectives
Main Development Processes identified by each standard are linked: Table 5.1: Development Processes by standard
ARP-4754A Development DO-178B/C Development DO-254 Development
Requirements & Functions Requirements Requirements
System Architecture Design Conceptual
Allocation of Requirements Coding Detailed
Implementation Integration Implementation
Transition to Production
The majority of Integral and Supporting Processes identified by each standard are linked as well: Table 5.2: Integral and Supporting Processes by standard
ARP-4754A Integral Processes DO-178B/C Supporting Processes DO-254 Supporting Processes
Configuration Management Configuration Management Configuration Management
Process Assurance Quality Assurance Process Assurance
Certification Authority Coordination Certification Liaison Certification Liaison
Verification Verification Verification
Requirements Validation Validation
Safety Assessment
DAL Assignment
Requirement Capture
ARP-4754A, DO-178B/C, DO-254 have a very “Extract from “Efficient Development of Safe important part in the overall systems Avionics Software with DO-178B Objectives Using development process. SCADE Suite®” handbook: Please consult our handbooks that thoroughly “The function and architecture of an embedded computer handle this matter. [DISPLAY-HB] and system (i.e., Flight Control, Braking, Cockpit Display, [SUITE-HB] etc.) are defined by system engineers; the associated control laws are developed by control engineers using some
Methodology Handbook 5 - 71 SCADE System with ARP-4754A Objectives
informal notation or a semi-formal notation mainly based on schema-blocks and/or state machines; and the 5.13 Integration and Verification embedded production software is finally specified textually and Validation and coded by hand in C or Ada by software engineers. In this context, qualified code generation from formal models is a technology that may carry strong Return on Successful system integration and integration Investment (ROI), while preserving the safety of the testing result from: application. Basically, the idea is to describe the • Accurate allocation of requirements to items application through a software model, including the control laws as described above, and to automatically • Careful interfaces definition generate the code from this model using a qualified code • True incremental life cycle integration generator, in the sense of DO-178B, resulting in the • Correct deployment of configuration management following advantages to the development life cycle: and other Systems Engineering management activities • When a proper modeling approach is defined: • Comprehensive integration testing strategy that • It fulfills the needs of the control engineers, typically using verifies the assembled system operates as it should such notations as data flow diagrams and state machines. In addition, especially for software items • It fulfills the needs of the software engineers by supporting the integration, a thorough path ranging from full accurate definition of the software requirements and by Virtual Integration to full Physical Integration is providing efficient automatic code generation of software having the qualities that are expected for such applications recognized as the most effective way to master (i.e., efficiency, determinism, static memory allocation, etc.). this extremely challenging Systems Engineering phase. • It allows for establishing efficient new processes to ensure that safety criteria are met. ANSYS Simplorer offers this capability, through • It saves coding time, as this is automatic. the FMI/FMU inter-modeling standard, to co- • It saves a significant part of verification time, as the use of simulate with SCADE Suite or SCADE Display. such tools guarantees that the generated source code conforms Then, a software item designed with SCADE to the software model. Suite or SCADE Display can be integrated in a • It allows for identifying problems earlier in the development virtual environment designed with ANSYS cycle, since most of the verification activities can be carried out Simplorer to fix the single and combined issues at model level. of the latest integration prior to integration in • It reduces the change cycle time, since modifications can be “the real world”. done at model level and code can automatically be regenerated.”
Methodology Handbook 5 - 72 SCADE System with ARP-4754A Objectives
Figure 5.25: Virtual integration of SCADE Suite application in Simplorer simulation
One of the major challenges in Virtual The capability of ANSYS Simplorer to Integration is the fidelity of the model that integrated Reduced Order Models (ROM) of represents the environment of the item under complex 3-D models is a way to reach this integration testing. fidelity objective.
Methodology Handbook 5 - 73 SCADE System with ARP-4754A Objectives
Figure 5.26: Power of ROM
When turning to the Verification and Validation • Hardware-in-the-Loop (HIL) testing combines real activities (Verification that the built item/system hardware components with software-based is rightly done, i.e., correctly responds to the simulation. requirements, Validation that the built item/ At this point, the conditions for accurate and system does right, i.e., does what the thorough testing are met, because HIL stakeholders expect), the following Virtual and environment in which the item/system is placed Physical Environments are respectively called: for testing has a larger scope of parameterization than the targeted real plant in • Model-in-the-Loop (MIL) testing involves simulation of the tested model coupled with a model of its which the item/system is placed at the end. environment. For example: • Software-in-the-Loop (SIL) testing evaluates the • Nominal testing and testing at boundaries of ranges functions of the generated or hand written code in co-simulation on the host machine. • Robustness testing: testing beyond specified ranges
Methodology Handbook 5 - 74 SCADE System with ARP-4754A Objectives
• Establishment of the test scenario that leads to the • Safety testing: testing at failure conditions Worst-Case Execution Time (WCET) – usually to SCADE Suite provides a gateway with National be measured in the real plant or to be analyzed/ Instrument LabVIEW toolset. altered with the real plant conditions
Figure 5.27: Example of HIL simulation with NI LabVIEW and SCADE System
Methodology Handbook 5 - 75 SCADE System with ARP-4754A Objectives
5.14 ARP-475A Tables Related to Implementation, Integration, and V&V
Objectives SCADE Model-Based Section Output Comments Systems Engineering Nr. Description Solution
Objective: ensure the system 5.0 Implementation Verification Process implementation satisfies the validated requirements
Test Engineers that have to design comprehensive Test or demonstration Verification integration test cases and 5.1 5.5.4.3 procedures are correct Procedures procedures can efficiently rely on the model of the system designed with SCADE System.
Verification demonstrates Verification intended functions and 5.5.1 Procedures 5.2 confidence of no 5.5.5.3 unintended function 5.5.5.2 impacts to safety Verification Results
Verification Procedures
Product implementation 5.5.1 Please consult our handbooks 5.3 complies with aircraft, and Specific item [DISPLAY-HB] and [SUITE- system requirements 5.5.2 verification activities HB] Verification Results are performed under DO-178B/ED-12B and DO-254/ED-80
See Appendix A, section 3.0, Safety Verification Safety requirements are 5.5.1 Assessment 5.4 Procedures and verified Objectives for specific 5.5.5.3 Results (ASA, SSA) safety objectives and control categories
Verification Matrix Verification compliance 5.5.6.3 5.5 substantiation is included 5.5.6.4 Verification Summary
Methodology Handbook 5 - 76 SCADE System with ARP-4754A Objectives
Objectives SCADE Model-Based Section Output Comments Systems Engineering Nr. Description Solution
Verification Assessment of deficiencies Summary 5.6 and their related impact 5.5.6.4 on safety is identified Problem Reports
All data from SCADE tools are easily managed in 6.0 Configuration Management Process configuration thanks to SCCI- based connection to the major Configuration Management tools.
Configuration items are 6.1 5.6.2.2 CM Records identified
Configuration baseline and Configuration 6.2 5.6.2.3 derivatives are established Baseline records
Problem reporting, change control, change review, Problem reports 6.3 5.6.2.4 and configuration status CM Records accounting are established
Archive and retrieval are 6.4 5.6.2.5 CM Records established
Methodology Handbook 5 - 77
SCADE System with ARP-4754A Objectives
6. Conclusions
This handbook identified the main challenges of We highlighted several advantages of the engineering a Civilian Avionics System that SCADE Model-Based Systems Engineering must meet ARP-4754A objectives: approach: • Establish the complete set of correct requirements • Modeling with SCADE System helps visualize the of the System entire system in its environment, thus facilitates the • Enable early safety analysis common understanding with users and other stakeholders • Build the preferred architecture of items that will be developed by specific teams • Modeling with SCADE System naturally disambiguate requirements and functions; in • Organize the requirements allocated to every items addition, SCADE System Checker allows checking • Set up interfaces of items and create naming for all duplications, naming consistency, and all other rules the teams that the Systems Engineering team thinks • Make decisions, create assumptions, produce useful appropriate data for all the teams • Iterations (adding details) and Increments • Constantly manage an truthful configuration of (completing the model) are facilitated System artifacts • Systems engineers stay focus on the primary • Manage a streamlined integration and V&V problem rather than on the document structure and consistency ESTABLISH THE COMPLETE SET OF CORRECT REQUIREMENTS OF THE SYSTEM • Dependencies and allocations are explicitly captured No other part of designing a System is as • difficult as establishing the System Documentation is automatically generated from the model Requirements. No other task has such important impact on the resulting system if We exposed, as well, that using SCADE done wrong. No other part of the Systems LifeCycle Requirements Management Gateway Engineering work is as costly to correct later. is key to validate the requirements completeness. We showed that graphically decomposing functions with SCADE System and modeling ENABLE EARLY SAFETY ANALYSIS operations using SCADE LifeCycle Rapid There is trend towards Model-Based Safety Prototyper both assist Systems engineers in Analysis (MBSA) that intends to automate validating the requirements correctness. portions of the safety Analysis process.
Methodology Handbook 6 - 79 SCADE System with ARP-4754A Objectives
MBSA is based on the existence of one or All the inner activities (from Requirements several formal models of the System. Analysis to Architecture Definition) of the SCADE MBSE are mostly focused on this Thus, MBSA relies on MBSE, and we objective: define the set of requirements that are demonstrated in this Handbook that the allocated to a given Item, thus to a given team. SCADE System architectural models are the primary inputs of the MBSA process. We illustrated how SCADE System, and its ecosystem, provides the path and the means to This joint approach carries several benefits: elaborate this outcome. • Tighter relationship between systems and safety analysis based on shared models SET UP INTERFACES AND NAMING AND PRODUCE USEFUL DATA • Earlier exploration of potential safety hazards, when it is less costly to introduce additional This is the also an extremely important outcome requirements for safety reason of the SCADE MBSE process. • Easier and faster verification of the impact of safety In order to keep all the implementations of requirements on the system architecture items in sync and to efficiently anticipate a
BUILD THE PREFERRED ARCHITECTURE OF ITEMS painless integration, it is mandatory to produce, distribute and keep updatable the interfaces and Models are often used to describe the naming included in the architecture. architecture of a System. In the same way, data contained within SCADE MBSE approach brings much more architectural descriptions aid the teams than just drawings. SCADE MBSE approach understanding and applying the system provides the opportunity to establish several structure. architectures and supports the synthesis and finally the design choice. We showed how SCADE System and SCADE Suite / SCADE Display synchronization feature We showed how SCADE System preserves the efficiently automates this Systems Engineering integrity of all artifacts designed at Systems task. Engineering level and distributes and maintains the elements required to keep all item Managing the Interface Control Documentation implementations in sync. (ICD) is a real pain. We indicated how SCADE System Data Dictionary features provide ALLOCATE THE REQUIREMENTS TO ITEMS Systems engineers with means to create and This is the primary outcome of the Systems store data related to contents of interfaces, and, Engineering process. This is about safe, on- also importantly, with means to export and time, accurate communication. import files of data.
Methodology Handbook 6 - 80 SCADE System with ARP-4754A Objectives
MANAGE THE CONFIGURATION OF SYSTEM ARTIFACTS progressive baselining of System artifacts, and We reminded you that Systems Engineering is finally to a proficient management of the an iterative and incremental problem solving Systems Engineering Project LifeCycle. process. STREAMLINE INTEGRATION AND V&V Secure management of system artifacts using Suitable integration of Items starts with a SCADE System inner model representation of reliable architecture and well-known interfaces diagrams, flows and tables of data, as well as between Items. SCADE LifeCycle RM Gateway and SCADE Configuration Management Interface, have been In addition, we exposed how the wide collection shown as efficient contributors to a safe of 0D at 3D modeling tools provided by ANSYS and partners are contributing to a cautious step-by-step Integration and V&V process, from virtual to physical.
Methodology Handbook 6 - 81
Appendixes and Index
SCADE System with ARP-4754A Objectives
A ARP-4754A Integral Process Tables
DEVELOPMENT PLANNING ELEMENTS
Planning Element Element Description 4754A sections
Establish the process and methods to be used to provide the framework Development for the aircraft/system architecture development, integration and 3 and 4.0 implementation.
Establish scope and content of the safety activities related to the Safety Program 5.1.5 development of the aircraft or system.
Identify and describe how the requirements are captured and managed. Requirements Management Sometimes these elements are included in conjunction with the 5.3 validation elements.
Describe how the requirements and assumptions will be shown to be Validation 5.4 complete and correct.
Define the processes and criteria to be applied when showing how the Implementation Verification 5.5 implementation satisfies its requirements.
Describe the key development related configuration items and how they Configuration Management 5.6 will be managed.
Describe the means to assure the practices and procedures to be Process Assurance 5.7 applied during system development are followed.
Describe the process and methods that will be used to achieve Certification 5.8 certification
The table below classifies objectives by DAL as • R: Recommended for certification follows: • A: As negotiated for certification • R*: Recommended for certification with process • N: Not required for certification independence 1
1. Independence for safety artifacts is achieved when the safety activity is performed by a person(s) other than the developer of the system/item.
Methodology Handbook A - 85 SCADE System with ARP-4754A Objectives
Table A.1: Process Objectives, Outputs, and System Control Category
Objectives Applicability and Independence by Development Assurance Level Section Output Nr. Description A B C D E
1.0 Planning Process
5.8.1 Certification Plan RRRRR 5.8.4.1
3.1 5.1.5 Safety Program Plan RRRRN App B
3.1 Development Plan RRRRN 5.8.4.3 System Development and integral 1.1 5.4.2a processes activities are defined Validation Plan RRRAN 5.4.7.1
5.5.3 Verification Plan RRRAN 5.5.5.1
Configuration 5.6.2.1 RRRRA Management Plan
Process Assurance 5.7.2 RRRRN Plan
Transition criteria and Plans in Objective 1.2 interrelationship among processes are 3.2 RRRAN N°1 defined
2.0 Aircraft and System Development Process and Requirements Capture
4.1.4 List of Aircraft-level Aircraft-level functions, functional functions 2.1 requirements, functional interfaces 4.2 RRRRN and assumptions are defined Aircraft-level 5.3 requirements
Aircraft functions are allocated to 4.1.5 System 2.2 RRRRN systems 4.3 Requirements
System requirements, including System 2.3 assumptions and system interfaces 5.3 RRRRN Requirements are defined
Methodology Handbook A - 86 SCADE System with ARP-4754A Objectives
Table A.1: Process Objectives, Outputs, and System Control Category (Continued)
Applicability and Independence by Objectives Development Assurance Level Section Output Nr. Description A B C D E
System derived requirements 4.4 (including derived safety-related System 2.4 5.3.1.4 RRRAN requirements) are defined and Requirements rationale explained 5.3.2
4.1.6 System Design 2.5 System architecture is defined 4.4 RRRAN Description 5.8.4.4
4.1.7 System requirements are allocated to 4.5 2.6 Item Requirements RRRRN the items 4.6 5.3
Appropriate item, system and aircraft 4.6.3 Verification 2.7 RRRAN integrations are performed 4.6.4 Summary
3.0 Safety Assessment Process
5.1.1 The aircraft/system functional hazard Aircraft FHA 3.1 5.2.3 R* R* R R R assessment is performed System FHA 5.2.4
5.1.2 The preliminary aircraft safety 3.2 5.2.3 PASA R* R* R A N assessment is performed 5.2.4
5.1.2 The preliminary system safety 5.1.6 3.3 PSSA R* R* R A N assessment is performed 5.2.3 5.2.4
Particular Risk RRANN Assessment
The common cause analyses are Common Mode 3.4 5.1.4 R* R* A N N performed Analysis
Zonal Safety RRANN Analysis
The aircraft safety assessment is 5.1.3 3.5 ASA R* R* R A N performed 5.1.6
Methodology Handbook A - 87 SCADE System with ARP-4754A Objectives
Table A.1: Process Objectives, Outputs, and System Control Category (Continued)
Applicability and Independence by Objectives Development Assurance Level Section Output Nr. Description A B C D E
The system safety assessment is 5.1.3 3.6 SSA R* R* R A N performed 5.1.6
System, HW, SW 5.3.2 Independence requirements in Requirements 3.7 functions, systems and items are 5.2.3 R* R* R R N PASA captured 5.1.3 PSSA
4.0 Requirements Validation Process
5.4 Aircraft, system, item requirements 5.4.2c 4.1 Validation Results R* R* R A N are complete and correct 5.4.3 5.4.4
Assumptions are justified and 4.2 5.4.2d Validation Results R* R R A N validated
5.3.1.4 Derived requirements are justified and 4.3 5.3.2 Validation Results R* R* R A N validated 5.4.2
5.4.3 4.4 Requirements are traceable Validation Results RRRAN 5.4.4
5.4.2e Validation Summary Validation compliance substantiation is 5.4.2f 4.6 (including Validation RRRAN provided 5.4.8 Matrix) 5.4.7.4
Methodology Handbook A - 88 SCADE System with ARP-4754A Objectives
Table A.1: Process Objectives, Outputs, and System Control Category (Continued)
Applicability and Independence by Objectives Development Assurance Level Section Output Nr. Description A B C D E
5.0 Implementation Verification Process
Test or demonstration procedures are Verification 5.1 5.5.4.3 R*RRAN correct Procedures
Verification 5.5.1 R*RRAN Verification demonstrates intended Procedures 5.2 functions and confidence of no 5.5.5.3 unintended function impacts to safety 5.5.5.2 Verification Results R*RRAN
Verification RRRAN Product implementation complies with 5.5.1 Procedures 5.3 aircraft, and system requirements 5.5.2 Verification Results R*RRAN
5.5.1 Verification 5.4 Safety requirements are verified Procedures and R* R* R A N 5.5.5.3 Results (ASA, SSA)
Verification Matrix R*RRAN Verification compliance substantiation 5.5.6.3 5.5 is included 5.5.6.4 Verification R*RRAN Summary
Verification R*RRAN Assessment of deficiencies and their Summary 5.6 5.5.6.4 related impact on safety is identified Problem Reports R*RRAN
6.0 Configuration Management Process
6.1 Configuration items are identified 5.6.2.2 CM Records RRRAN
Configuration baseline and derivatives Configuration 6.2 5.6.2.3 RRRAN are established Baseline records
Problem reporting, change control, Problem reports 6.3 change review, and configuration 5.6.2.4 RRRRN status accounting are established CM Records
6.4 Archive and retrieval are established 5.6.2.5 CM Records RRRRN
7.0 Process Assurance Process
Methodology Handbook A - 89 SCADE System with ARP-4754A Objectives
Table A.1: Process Objectives, Outputs, and System Control Category (Continued)
Applicability and Independence by Objectives Development Assurance Level Section Output Nr. Description A B C D E
Assurance is obtained that necessary Evidence of Process 7.1 plans are developed and maintained 5.7.3 RRRAN Assurance for all aspects of system certification
Development activities and processes Evidence of Process 7.2 are conducted in accordance with 5.7.4 RRRAN Assurance those plans
8.0 Certification and Regulatory Authority Coordination Process
Certification 5.8.3 R* R* R* R N Summary 8.1 Compliance substantiation is provided 5.8.4.2 Configuration Index R* R* R* R N
Methodology Handbook A - 90 SCADE System with ARP-4754A Objectives
B References
[ANSI/AIAA] “Guide for the Preparation of [DOT/FAA/AR-08] “Guidelines for the Development Operational Concept Documents”, of a Critical Composite ANSI/AIAA G-043- 1992. Maintenance and Repair Issues [ARINC 429] Aerospace standard that describes Awareness Course”, U.S. the architecture, interfaces, and Department of Transportation, protocol to carry data on a data- Federal Aviation Administration, bus. Published 2001. DOT/FAA/AR-08/54, February 2009. [ARP-4754A] “Guidelines for Development of [DOT/FAA/AR-08/32] “Requirements Engineering Civil Aircraft and Systems”, Society Management Handbook”, FAA, of Automotive Engineers, 2010-12. June 2009. [ARP-4761] “Guidelines and Methods for [IEEE P1220] “Standard for the Application and Conducting the Safety Assessment Management of the Systems Process on Civil Airborne Systems Engineering Process”, IEEE, [Final and Equipment” Society of Draft], September 1994. Automotive Engineers, 1996. [IEEE 610.12-1990] “Standard Glossary of Software [ARP-5056] “Flight Crew Interface Engineering Terminology”, IEEE. Considerations in the Flight Deck [IEEE 1471-2000] “Recommended Practice for Design Process for Part 25 Aircraft”, Architectural Description for Society of Automotive Engineers, Software-Intensive Systems”, IEEE. 2006. [INCOSE] “Systems Engineering Handbook. A [DISPLAY-HB] Efficient Development of Safe Guide for System Lifecycle Processes Avionics Software with DO-178B and Activities”, INCOSE-TP-2003- Objectives Using Esterel SCADE ®, 002-03.2, January 2010. Second Edition (revision 1), Esterel [ISO/IEC15288] “Systems and Software Engineering Technologies, February 2012. - System Life Cycle Process”, ISO/IEC [DO-178B/ED-12B] “Software Considerations in 15288:2008. Airborne Systems and Equipment [RTCA/DO-254] “Design Assurance Guidance for Certification”, RTCA/EUROCAE, Airborne Electronic Hardware”, December 1992. RTCA SC-180, EUROCAE WG-46, [DO-248B/ED-94B] Final report for clarification of DO- April 19, 2000 178B “Software Considerations in [RTCA/DO-178B] “Software Considerations in Airborne Systems and Equipment Airborne Systems and Equipment”, Certification”, RTCA Inc, October RTCA, January 2012. 2001. [SUITE-HB] Efficient Development of Safe [DO-254/ED-80] “Design Assurance Guidance for Avionics Software with DO-178B Airborne Electronic Hardware”, Objectives Using SCADE Suite®, RTCA Inc, April 2000. Fifth Edition (revision 2), Esterel Technologies, January 2012. [SYSTEM-UM] “SCADE System User Manual”, Version 2.0 release, Esterel Technologies, March 2013.
Methodology Handbook B - 91
SCADE System with ARP-4754A Objectives
C Acronyms and Glossary
ACRONYMS
A/C Aircraft IDAL Item Development Assurance Level API Application Programming Interface LLR Low-level Requirement ARP Aerospace Recommended Practices MBSE Model-Based Systems Engineering CCA Common Cause Analysis MC/DC Modified Condition/Decision Coverage CONOPS CONcept Of OPerationS MIL Model-in-the-Loop COTS Commercial Off-The-Shelf N/A Not Applicable DAL Development Assurance Level N.B. Nota Bene EASA European Aviation Safety Agency PSSA Preliminary System Safety Assessment ECU Electronic Control Unit RM Requirements Management EUROCAE European Organization for Civil Aviation ROI Return On Investment Equipment RTCA Radio Technical Commission for FAA Federal Aviation Administration Aeronautics FDAL Functional Development Assurance Level SAE Society of Automotive Engineers FHA Functional Hazard Analysis SCADE Safety Critical Application Development FMI/FMU Functional Mock-up Interface / Functional Environment Mock-up Unit SCCI Source Code Control Interface HIL Hardware-in-the-Loop SDPD Simulation-Driven Product Development HLR High-level Requirement SE Systems Engineering ICD Interface Control Documentation SGL Standard Graphic Library IDE Integrated Development Environment SIL Software-in-the-Loop IEC International Electrotechnical SQA Software Quality Assurance Commission SRATS System requirements allocated to ILS Instrumented Landing System software INCOSE International Council on Systems SSA System Safety Assessment Engineering SSM SCADE State Machine IP Intellectual Property SW Software ISO International Organization for TRL Technology Readiness Level Standardization V&V Verification and Validation HTML HyperText Markup Language WCET Worst Case Execution Time
Methodology Handbook C - 93 SCADE System with ARP-4754A Objectives
GLOSSARY
0D-Simulation Hardware-in-the-Loop (HIL) 0D-Simulation of a model does not handle spatial HIL provides a simulation platform that incorporates dimensions. Only time dimension is considered. 0D- ways to flexibly handle the behavior of the plant (i.e., Model is an approximation, in general via the environment) of the component under test. mathematical equations, of a 3D-domain problem. Hardware/software integration Certification The process of combining the software into the target Legal recognition by the certification authority that a computer. product, service, organization, or a person complies with the requirements. Such certification comprises the High-level requirements activity of technically checking the product, service, Software requirements developed from analysis of organization, or person, and the formal recognition of system requirements. compliance with the applicable requirements by issue of a certificate, license, approval, or other documents Host computer as required by national laws and procedures. In The computer on which the software is developed. particular, certification of a product involves: (a) the process of assessing the design of a product to ensure Independence that it complies with a set of standards applicable to Separation of responsibilities, which ensures the that type of product so as to demonstrate an accomplishment of objective evaluation. (1) For acceptable level of safety; (b) the process of assessing software verification process activities, independence is an individual product to ensure that it conforms with achieved when the verification activity is performed by the certified type design; (c) the issuance of a a person(s) other than the developer of the item being certificate required by national laws to declare that verified, and a tool(s) may be used to achieve an compliance or conformity was found with standards in equivalence to the human verification activity. (2) For accordance with items (a) or (b) above. the software quality assurance process, independence also includes the authority to ensure corrective action. Certification credit Acceptance by the certification authority that a Integral process process, product, or demonstration satisfies a A process that assists the software development, certification requirement. processes, and other integral processes and, therefore, remains active throughout the software life cycle. The Failure integral processes are the software verification process, The inability of a system or system component to the software quality assurance process, the software perform a required function within specified limits. A configuration management process, and the failure may be produced when a fault is encountered. certification liaison process.
Fault Item A manifestation of an error in software. A fault, if it A hardware or software element having bounded and occurs, may cause a failure. well-defined interfaces [ARP-4754A] Fault toleranceThe built-in capability of a system to provide continued correct execution in the presence of Low-level requirements a limited number of hardware or software faults. Software requirements derived from high-level requirements, derived requirements, and design Formal methodsDescriptive notations and analytical constraints from which source code can be directly methods used to construct, develop, and reason about mathematical models of system behavior. implemented without further information.
Methodology Handbook C - 94 SCADE System with ARP-4754A Objectives
Mechatronics Test case “Mechatronics” defines objects that are made of A set of test inputs, execution conditions, and expected hardware mechanics, hardware electronics, and results developed for a particular objective, such as to software. exercise a particular program oath or to verify compliance with a specific requirement. Model-in-the-Loop (MIL) MIL is a version of SIL, where the simulation of the Tool qualification component and its environment is handled at model The process necessary to obtain certification credit for level. a software tool within the context of a specific airborne system. Modified Condition/Decision Coverage Every point of entry and exit in the program was Traceability invoked at least once, every condition in a decision in The evidence of an association between items, such as the program has taken all possible outcomes at least between process outputs, between an output and its once, every decision in the program has taken all originating process, or between a requirement and its possible outcomes at least once, and each condition in implementation. a decision was shown to independently affect that decision's outcome. A condition is shown to Validation independently affect a decision's outcome by varying The process of determining that the requirements for a just that condition, while holding fixed all other product are correct and complete. Are we building the possible conditions. right aircraft system/function/item? [ARP-4754A]
Reduced Order Model Verification A Reduced Order Model is an approximation model of The evaluation of an implementation of requirements a complex model, by canceling one or more of its to determine that they have been met. Did we build dimensions (from 3D to 2D: a thin parallelepiped can the aircraft system/function/item right? [ARP-4754A] be approximated by a rectangle; from 3D to 1D: a thin tube can be reduced as a thread; from 3D to 0D: an Widget electrical circuit can be replaced by an equivalent In computer programming, a widget is an element of a equation). graphical user interface (GUI) that displays an information arrangement changeable by the user, such Robustness as a window or a text box. The defining characteristic The extent to which software can continue to operate of a widget is to provide a single interaction point for correctly despite invalid inputs. the direct manipulation of a given kind of data. In other words, widgets are basic visual building blocks Software-in-the-Loop (SIL) which, combined in an application, hold all the data SIL provides a pure software simulation platform, processed by the application and the available where the plant behavior is emulated by software. interactions on this data. (Source: Wikipedia)
Standard A rule or basis of comparison used to provide both guidance in and assessment of the performance of a given activity or the content of a specified data item.
Methodology Handbook C - 95
SCADE System with ARP-4754A Objectives
D Software Simulation with SCADE Suite, SCADE Display, and ANSYS Simplorer
The virtual prototyping capabilities of SCADE SCADE System is providing a function of Suite, SCADE Display and ANSYS Simplorer synchronization with SCADE Suite and working together are efficient to rapidly develop SCADE Display, in order to pass and maintain virtual prototypes which are essential the detailed architectural artifacts and interfaces contributors of the Requirements Validation elaborated at system level. process, making sure that requirements are understood and correct. As shown in Figure D.1 and Figure D.2, SCADE Suite and SCADE Display are DO-178B/C qualified Model-Based Development tools that reduce cost, risk, and time-to-certification.
Figure D.2: HMI modeling with SCADE Display
The management of requirements and their traceability links is enabled by SCADE LifeCycle Requirements Management Gateway, as presented in Figure D.3.
Figure D.1: Software modeling with SCADE Suite
Methodology Handbook D - 97 SCADE System with ARP-4754A Objectives
Requirements Management Gateway
Figure D.3: Managing Requirements with SCADE LifeCycle
The overall ANSYS vision of System Software-in-the-Loop (SIL) and Hardware-in- Integration and V&V driven by simulation is the-Loop (HIL), the progressive nature of presented in Figure D.4. From complete Virtual Integration and Verification is accompanied. Simulation to Model-in-the-Loop (MIL),
Simplorer Control Modeling
HMI Modeling
Plant Modeling
Figure D.4: Conceptual analysis and virtual prototyping with ANSYS tools
Methodology Handbook D - 98 SCADE System with ARP-4754A Objectives
Index
Integral process Widget Symbols glossary 94 glossary 95 0D-Simulation 53 Item glossary 94 glossary 94 C L CCA LLR acronym 93 acronym 93 CONOPS acronym 93 M MBSE D acronym 93 DAL MC/DC acronym 93 acronym 93 Modified Condition/Decision F Coverage glossary 95 Failure glossary 94 Fault R glossary 94 Reduced Order Model FDAL glossary 95 acronym 93 S H SSM High-level requirements acronym 93 glossary 94 HLR T acronym 93 TRL I acronym 93 IDAL W acronym 93 WCET IDE acronym 93 acronym 93
Methodology Handbook 99 Contact Information
Submit questions to Technical Support at [email protected]
Contact one of our Sales representatives at [email protected]
Direct general questions about Esterel Technologies to [email protected]
Discover the latest news on our products and technology at http://www.esterel-technologies.com
Copyright © 2013 Esterel Technologies - A wholly-owned subsidiary of ANSYS, Inc. All rights reserved Esterel Technologies SA. [SSY-HB-ARP4754]