Free Courses

[Solution]

This article is part of a DO-178C blog series. It gives an overview of the DO-178C avionics software standard and details the process of developing, then verifying, safe compliant applications. You can find links to each part below:

• Part 1: An introduction to DO-178C
• Part 2 (this blog): Efficient Development of Safe Avionics Software with DO-178C Objectives Using SCADE Suite
• Part 3: Efficient Verification of Safe Avionics Software with DO-178C Objectives Using SCADE Suite

In a previous blog, we introduced DO-178C, officially titled “Software Considerations in Airborne Systems and Equipment Certification”, the key document in the aerospace industry, providing guidelines for the development of airborne software.

In this blog, we provide an overview on how to fully satisfy DO-178C objectives with a SCADE Suite model-based approach for developing avionics software. A later blog will cover the Verification side of DO-178C.

A more detailed presentation of the regulatory guidance and how to satisfy DO-178C objectives with SCADE is available from our website.

Model-Based Development with SCADE

SCADE Suite is a software design product line for embedded control software modeling, verification, and code generation. SCADE Suite provides a user-friendly and intuitive model-based environment for software engineers.

The SCADE Suite product highlights are the following:

• Embedded Control Software Design: streamlined development of control systems, logic, and algorithms within an integrated environment. Combines data flow and state machine operators seamlessly, enabling flexibility and precision at any level of design.
• Integrated Suite for Prototyping, Modeling, Simulation, Verification and Optimization: efficient debugging and optimization of software models and code size, speed, and performance.
• Safe Code Generation: automatic C and Ada qualified code generators (DO-178C/DO-330, EN 50128, ISO 26262, IEC 61508) also the basis for testing cost reduction.

Model-based software design with safe code generation

SCADE Suite as a model-based development environment

SCADE Suite enables a model-based development approach:

• SCADE Suite models are usually considered design models. They mainly represent the software low-level requirements and software architecture. Such models rely on a formally defined notation.
• Models can be managed under configuration control.
• Documentation is automatically and directly generated from models: it is correct and up to date by construction.
• A syntactic and semantic check is performed automatically to verify that the models respect Scade syntax and semantics.
• Formal verification techniques can be directly applied to models to detect corner case defects (e.g. division by 0) or to prove safety properties.
• Time and stack analysis can be conducted to verify early compatibility between the model and the target platform, ensuring execution time and memory requirements are met.
• Target compatibility with SCADE Suite KCG-generated code can also be verified on a representative code sample (using SCADE Suite Compiler Verification Kit), to anticipate potential issues with the cross-compiler used to generate the target EOC.
• Code is automatically and directly generated from models with the KCG qualified Code Generator: the source code complies with the semantics of the input model.
• SCADE Suite generated code can be wrapped in an RTOS task, thus implementing the needed cyclic function.
• The DO-178C Certification Kit provides all the evidence that is needed to qualify SCADE Suite KCG at DO-330/ TQL-1.

SCADE Suite also integrates a testing environment with SCADE Test:

• Models can be exercised by simulation to dynamically verify their behavior according to upper-level requirements.
• Model coverage analysis can be performed to assess how thoroughly the model was tested and to detect unintended functions in the model.

SCADE Suite applies these “golden rules”:

• Share unique and accurate specifications.
• Do things once: do not rewrite descriptions from one activity to another.
• Do things right in the first place: detect errors in the early stages of a project.

SCADE Suite allows saving time spent on significant verification efforts because models can be verified as soon as they are available (even in parts) thus avoiding situations where code must be developed before any verification can start and every error that is detected requires a lengthy change cycle.

SCADE Suite models formalize a significant part of the software architecture and detailed design. The model is written and maintained once in the project and shared among team members. Expensive and error-prone rewriting is thus avoided; interpretation errors are minimized. All members of the project team, from the specification team to the review and testing teams, can share models as a reference.

SCADE modeling and safety benefits

SCADE Suite strongly supports safety at model level because:

• The Scade language is rigorously defined. Its interpretation does not depend on readers or any tool. It relies on more than 25 years of academic research (Esterel, Lustre).
• The Scade language is simple. It relies on very few basic concepts and simple combination rules of these concepts.
• Control structures remain at a high level of abstraction. For example, array operations in SCADE Suite are expressed as such and do not require low-level loops and indexes. There is no need for goto’s, no need for the creation of memory at runtime, no way to incorrectly access memory through pointers or an index out of bounds in an array. Moreover, these principles are reflected in the generated code out of SCADE Suite KCG.
• The Scade language contains features oriented towards safety like strong typing, mandatory initialization of flows.
• SCADE Suite models are deterministic. A system is deterministic if it always reacts in the same way to the same inputs occurring with the same timing. In contrast, a non-deterministic system can react in different ways to the same inputs, the actual reaction depending on internal choices or computation timing.
• The Scade language provides a simple and clean expression of concurrency at functional level (data flows express dependencies between operators). Within a model, this avoids the traditional problems of deadlocks and race conditions.
• SCADE Suite performs the complete verification of language syntactic and semantic rules, such as type and clock consistency, initialization of data flows, or causality in models.

Software Development Activities with SCADE Suite

Overview of Software Development Activities

A typical SCADE Suite software development process is a combination of Model-Based Development together with qualified code generation. The following figure shows the software development processes and where SCADE Suite is used.

Software development processes with SCADE Suite

SCADE Suite models are extensively used in the software design process to develop major parts of the architecture and the low-level requirements. Such models are design models according to the DO-331 definition. The corresponding source code is then automatically generated from the models by using SCADE Suite KCG.

Traceability within the software development process (as defined in §5.5 of DO-178C) requires bi-directional traceability between:

• System requirements allocated to software and HLR.
• HLR and LLR (i.e., SCADE Suite model). The traceability process between HLR and SCADE Suite models is supported by SCADE LifeCycle Application Lifecycle Management (ALM).
• LLR and source code.

Software Requirements Process

In DO-178C terminology, the inputs to the Software Requirements Process are the System Requirements allocated to Software (SRATS).

The software requirements process produces the HLRs. These HLRs usually include functional, performance, interface, and safety-related requirements. The logic requirements (logic HLRs) are usually in textual form.

Software Design Process with SCADE Suite

As explained in DO-178C §5.2, “the high- level requirements are refined through one or more iterations in the software design process to develop the software architecture and the low-level requirements” The following figure illustrates the design flow with SCADE Suite.

Software design process with SCADE Suite

Architecture design

The first step in the design process is to define the global application architecture, considering SCADE Suite and manual software elements.

The application is decomposed functionally into its main components. The characteristics of these components serve as a basis for allocating their refinement in terms of techniques (Scade, C, …) and team. Among those characteristics, one must consider, for a software component:

• The type of processing (e.g., decision logic, byte encoding).
• The volume of communication it has with other components.
• The interaction it has with hardware or the operating system (e.g., direct memory access, interrupt handling).
• Its activation conditions (e.g., initialization) and frequency (e.g., 100 Hz).

SCADE Suite is well-adapted to the functional parts of the software, such as decision logic, filtering, or control. It may be less appropriate for low-level software such as hardware drivers, interrupt handlers, and encoding/decoding routines which may be implemented in C or Rust.

An architecture design model can be developed in SCADE Suite, the data flow consistency will be automatically verified using SCADE Suite semantic checks. It is also possible to use SCADE Architect for designing the software architecture and synchronizing this model with SCADE Suite.

The purpose of the software architecture design model is to:

• Identify high-level functions: typically, one develops a functional breakdown down to a depth of two or three.
• Define the interfaces of these functions: names, data types.
• Describe the data flows and control flows between these functions.
• Verify consistency of the data flows between these functions using SCADE Suite semantic checks.
• Prepare the framework for the detailed design process: defining the top-level functions while ensuring consistency of their interfaces.

Top-level view of a simple Flight Control System

This architecture design model is extremely important because it lays the foundations for the logic LLRs.

A good architecture aims at ensuring:

• Stability and maintainability: The team needs a stable framework during the initial development as well as when there are updates.
• Readability and verifiability: Readability comes naturally through the clear and unambiguous Scade language semantics, and simple and intuitive graphical symbology. Verifiability comes naturally with a formal notation such as the Scade language, but also requires minimizing the complexity of the model.
• Efficiency: There is no silver bullet for achieving a good model architecture with SCADE products. It requires a mix of experience, creativity, and rigor.

SCADE low-level requirements development

Once the SCADE Suite architecture is defined, the logic architecture models are refined to design the low-level requirements (LLR). The objective of this activity is to produce a set of complete and consistent SCADE Suite design models.

The definition and granularity of an LLR in SCADE Suite models is determined by the user themselves. For instance, LLRs can be mapped to:

• user-defined operators (nodes or functions declared by users to define operators with/without memory, imported operators).
• diagrams (graphical or textual representation of dataflow and states).
• or equation sets (grouping design elements graphically in diagrams to allow global commenting, annotating, or tracing).

The Scade language includes both a graphical and a textual representation. It supports a modeling style that brings together capabilities to design complex decision logic, filtering, and control. These elements can be combined without restriction while the modularity of the design is continuously supported. This language efficiently supports good practices for the development of high-integrity software such as: encapsulation (modularity), strong typing, concurrency and re-usable components (interface definition, genericity, library).

Reusable components and library management

A SCADE Suite library object is developed as any other SCADE Suite software component, considering the following considerations:

• Library components are usually identified during the design process of a given application and can be considered in most cases as implementation choices, not necessarily described in the upper-level requirements (HLR) of the application.
• Good practice consists in defining functional requirements (derived HLRs) for these library components as a separate document and in developing and verifying the components from its derived HLRs.
• When a library is shared between several applications, a self-contained development package may be considered, including its own set of life cycle data (project plans and standards, requirements, design data, verification reports, …).

Robustness management

Robustness of safety critical software cannot be addressed locally. It requires a general robustness policy for the whole system and should be addressed at each step of the development and verification processes.

The robustness policy should be defined in the Software Design Standards, Software Coding Standards, and Software Architecture Design Document. As an example, the way of handling arithmetic exceptions should be defined at this global level.

There should be explicit decisions about robustness and failure handling in the software requirements.

The HLR (including derived HLR for library components) should specify responses to abnormal input data and to any invalid data that may be produced by computation described in the HLR (e.g., for X=Y/Z, the HLR should specify the expected behavior to Z near zero, except if there is evidence that Z is far from zero, or more precisely that Y/Z cannot generate a division by zero). This is required to achieve accuracy and determinism of requirements and to perform requirements-based testing for robustness tests.

Debugging SCADE Suite Models

In SCADE Suite, software design can be seamlessly debugged. The debugger leverages the actual code generated by SCADE Suite and provides a robust visual debugging environment with features such as:

• Defining stop conditions and setting breakpoints.
• Inspecting internal variables and output values in real-time.
• Recording and replaying scenarios for comprehensive testing.

Scenarios are stored in an ASCII format, enabling easy integration of the simulation phase into existing workflows and toolchains. Additionally, simulation tasks can be tailored and automated using scripting languages like Python, offering flexibility and efficiency in the debugging process.

Your SCADE design can also be reused by directly integrating the generated code or a FMU in a system level simulator.

Software Coding Process

The SCADE Suite KCG code generator automatically generates the complete code that implements the software design defined in formal notation for both data flows and state machines.

Software coding process with SCADE Suite

Code generation from SCADE Suite models

The model completely defines the expected behavior of the generated code. The code generation options define the implementation choices for the software. However, these options never complement nor alter the behavior of the model.

In addition, the generated code has the following properties:

• The code is portable and ISO C, MISRA C and CERT C compliant.
• The code structure reflects the model architecture for data-flow parts when there is no expansion and/or optimization during code generation. For control-flow parts, traceability between state names and C code is ensured.
• The code is readable and traceable to the input model through the use of corresponding names, specific comments, etc..
• Memory allocation is fully static (no dynamic memory allocation).
• There is no recursive call.
• Only bounded loops are allowed, since they use static values known at code generation time.
• Execution time is bounded.
• No dynamic address calculation is performed (no pointer arithmetic).
• There are no implicit conversions and no expression with side-effects (no i++, no a += b, no side-effect in function calls).
• No functions are passed as arguments.

To support automated code integration and compilation a Python Integration Toolbox is provided.

Tuning code to target and project constraints

Various code generation options can be used to tune the generated code to a particular target and project constraints. Static analysis methods are available using SCADE Suite Timing and Stack Optimizer. Specified as a SCADE Suite model, the applicative software can be analyzed from the execution time point of view allowing to tune modeling choices and code generation options according to users’ needs.

Basically, there are two ways to generate code from an operator:

• Non-expanded mode: the operator is generated as a function.
• Expanded mode: the whole code for the operator is inlined where it is called.

Both code generation modes (Non-expanded or Expanded) can be composed at will, performing a call for some operators and inlining for other operators.

Additional directives are also available:

• The global_root_context SCADE Suite KCG option is a code generation mode where the inputs, outputs and context variables of the root operators are defined as C global variables and not passed as arguments of the root C functions.
• The separate_io SCADE Suite KCG option and/or pragma applies to an operator. When it is set, the code generated for the cycle function is different: outputs are no more in the context but passed as separate parameters.

These two options impact performance and stack size.

Note that the expansion and interface directives may have an impact on the structure of the generated code, on the integration of the generated code, and even on the verification strategy.

These options and directives can be considered as a design choice and should be identified early in the software development life cycle, preferably during architecture decomposition.

Code generation from multiple components

The SCADE Suite KCG code generator is specified and designed for verifying a complete application and generating the corresponding complete set of C files in one global run, in order to ensure consistency of the generated code (typically generated C type names).

This process ensures global consistency of the code generated from a single SCADE Suite component. Yet, it may not be appropriate in the context of complex software architecture. A complex SCADE Suite application can result from several components (interacting or not together) where each component corresponds to a single model with a given root node. It is the case for instance, when the SCADE Suite application includes several tasks and each task is designed with a separate model.

As shown in the figure below, there are two alternatives for generating code:

• Generating all code in one run, using the “multi-root” SCADE Suite KCG option. When operators do not belong to the same model, a new integration model, which references the input models, is required.
• Generating code for each root node separately and then manually integrating generated codes into the application.

Note that the first alternative is highly recommended unless there is a major reason for not using it. It is the safest and cleanest way to integrate the different root nodes. It is also highly recommended as a means for performing verification and validation of the global behavior.

Code generation and multiple components

A more detailed presentation can be found in “How to integrate multiple SCADE models into one executable” blog.

Software Integration Process

The integration of a SCADE application is about:

• Interface with the external environment (Inputs/Outputs)
• SCADE Suite module integration
• Integration of external data and code
• Scheduling and tasking

Interface to physical sensors and/or to data buses is usually handled by drivers. These drivers are usually not developed in Scade but in C or assembly language.

SCADE Suite module integration

A module refers here to the code generated by SCADE Suite KCG from a SCADE Suite component. Depending on the selected code generation process, the user must manage the integration of one or several modules with the rest of the software application.

Module integration depends on the implementation of predefined Scade types which must be mapped to C types. A default type definition is given in the generated code but it is possible to redefine these default types by providing the implementation of each basic type in a user configuration file.

Integration of external code

SCADE Suite allows referencing external code in models. Scade includes the concept of imported constants, types, and functions. The declaration of these external data is performed at model level in Scade whereas their definition is given in C language.

For model simulation purposes, SCADE Test automatically compiles and links external code when the path names of the source files are given in the project settings.

Scheduling and tasking

Scheduling must be addressed in the preliminary design phase, but for the sake of simplicity it is described below.

The SCADE Suite execution semantics is based on a cycle-based execution model. This model can be represented with the following figure.

SCADE Suite execution semantics

The software application samples the inputs from the environment and sets them as inputs for the SCADE Suite generated code. The main SCADE Suite function of the generated code is called. When code execution ends, the calculated outputs can be used to act upon the environment. The software application is ready to start another cycle.

A bare metal implementation is straightforward; the cycle can be started in different ways:

• Polling: a new cycle is started immediately after the end of the previous one in an infinite loop.
• Event triggered: a new cycle is started when a new start event occurs.
• Time triggered: a new cycle is started regularly, based on a clock signal.

The SCADE generated code can be simply included in an infinite loop, waiting or not for an event or a clock signal to start a new cycle.

begin_loop
    wait for an event (usually clock signal)
    set SCADE Suite inputs
    call SCADE Suite-generated main function
    use SCADE Suite outputs
end_loop

A SCADE Suite design can be easily integrated into an RTOS task as shown below. The infinite loop construct is replaced by a task. This task is activated by the start event of the design, which can be a periodic alarm or a user activation.

SCADE Suite code integration

This architecture can be designed by hand for any RTOS. The SCADE Code Integration Toolbox allows to automate code production and integration, and examples are provided for different commercial OS.

Note that concurrency is expressed functionally in SCADE Suite models and that SCADE Suite KCG takes into account data flow dependencies to generate sequential code. There is no need for the user to spend time sequencing parallel flows, neither during modeling nor during implementation. There is no need to develop multiple tasks with complex and error-prone synchronization mechanisms. Other code, such as hardware drivers, may run in separate tasks, provided they do not interfere with the SCADE Suite generated code.

Stay tuned

In this blog, we demonstrated how using SCADE Suite’s model-based approach for the development of critical certified software offers several key benefits:

Compliance with Safety Standards

• Qualified code generators reduce the effort and cost of certification, ensuring compliance with stringent industry requirements.

Improved Efficiency and Productivity

• The graphical, model-based approach minimizes manual coding, reducing development time and increasing productivity.
• Automated code generation eliminates errors introduced by hand coding, accelerating the development life cycle.

Enhanced Design Consistency and Traceability

• Unified models provide a single source of truth for system design, ensuring consistency across components.
• Built-in traceability features support end-to-end linking between requirements, design, and test cases, making it easier to manage complex projects and audits.

High Reliability and Quality

• Formal verification and simulation capabilities ensure that models are robust, predictable, and free from errors before deployment.
• The use of deterministic code generation leads to highly reliable and maintainable code, suitable for safety applications.

Reduced Certification Costs

• By leveraging SCADE’s qualified code generators, teams can reduce the time, effort, and cost required to certify critical software.

Ease of Maintenance and Scalability

• Models are easier to understand, maintain, and modify compared to traditional code, making updates and scalability simpler.
• Reusable components within SCADE Suite allow for faster iteration and development in future projects.

Early Error Detection

• SCADE’s simulation and testing tools allow for early detection and correction of design errors, reducing downstream costs and risks.

Seamless Integration

• SCADE Suite supports seamless integration with other tools and platforms, enabling compatibility with larger system designs and workflows.

By combining these benefits, SCADE Suite’s model-based development approach ensures that critical software is developed efficiently, reliably, and in compliance with the highest safety standards.

In a future blog, we will show how tools like SCADE Test and SCADE Design Verifier support verification and validation to further reduce the manual effort involved in achieving certification.

If you’d like to know more about how Ansys SCADE can improve your embedded DO-178C workflow, you may contact us from the Ansys Embedded Software page.

About the author

Gunther Siegel (LinkedIn) leads the Embedded Software product line within Ansys. In this role, he acts as the primary technical interface with strategic customers and partners, driving collaboration and innovation. Mr. Siegel brings over 15 years of expertise in technical leadership, product development and strategic business growth.