We have an exciting announcement about badges coming in May 2025. Until then, we will temporarily stop issuing new badges for course completions and certifications. However, all completions will be recorded and fulfilled after May 2025.
Embedded Software

Embedded Software

Memory-safe languages and what it means for SCADE

    • SolutionSolution
      Participant

      In the past few months, you may have read news or LinkedIn posts like ‘White House Urges Devs To Switch To Memory-Safe Programming Languages’ or ‘White House urges developers to dump C and C++’. But what does it mean exactly? Should you be worried as a SCADE user? Or should it reinforce your decision to use SCADE? In this blog post, we’ll tell you about this recently published directive and we’ll explain why SCADE is safe and secure by construction.



      About the White House directive

      On February 26, 2024, the White House Office of the National Cyber Director (ONCD) published a technical report entitled “Back to the Building Blocks: A Path Toward Secure and Measurable Software“. In particular, this report recommends using ‘memory-safe programming languages, that can eliminate most memory safety errors’ (see this fact sheet for a summary).

      Industry analysis has shown in some cases, that despite rigorous code reviews as well as other preventive and detective controls, up to 70 percent of security vulnerabilities in memory-unsafe languages patched and assigned a CVE designation are due to memory safety issues. When large code bases are migrated to a memory-safe language, evidence shows that memory safety vulnerabilities are nearly eliminated.

      NB: the Common Vulnerabilities and Exposures (CVE) is a public catalog of disclosed cybersecurity vulnerabilities.

      Memory-safe languages are programming languages that prevent programmers from introducing certain types of bugs related to how memory is used: out-of-bounds reads and writes (e.g., read or write beyond the end of an array), use-after-free (accessing memory that has been freed), etc.

      In the embedded world, Rust and Ada are considered memory-safe languages. C and C++ are not memory-safe. Special care needs to be taken, with standards like MISRA C or CERT C providing coding rules to avoid such memory errors. Applying and verifying such rules takes a lot of time and effort. What if there was an easier way?

      What about SCADE?

      Modeling in SCADE Suite is based on a domain-specific language called Scade 6, designed for creating safe and reliable embedded applications. This language supports both diagrammatic and textual notations. Swan is the name of the language used in Scade One, and it is an evolution of Scade 6.

      Scade 6 and Swan are memory-safe languages:

      • Key safety properties are guaranteed by construction (it means that the properties are true for all models that are accepted by the code generator), like the absence of out-of-bounds reads and writes for arrays and other properties like bounded memory and reaction time. There is no need for a safe subset or modeling rules like with other model-based approaches.
      • Type safety is also ensured through a strong typing system (e.g. no implicit casts, no unsafe unions).
      • Scade 6 and Swan do not allow (nor require) any manipulation of memory or pointers. Memory is statically allocated at the beginning of execution, avoiding any use-after-free errors.

      The C code generated from a Scade model is safe and secure by construction. We have shown the compliance of the C code generated by KCG 6.6 with the CERT C standard. The qualification of the code generator, for the highest level of safety standards, ensures that no activities are needed on the generated C code.

      This makes Scade 6 or Swan safe and secure for experts and non-experts, avoiding the pitfalls of a general-purpose language like C/C++.

      SCADE and Rust

      Rust is often cited as a modern, memory-safe alternative to C/C++, that is used in embedded software nowadays. But Rust will not replace SCADE. In fact, SCADE and Rust have different use cases and can co-exist in the same application.

      Rust is a general-purpose programming language. Its main use case is low-level systems programming, performance-critical code. Rust guarantees many properties through a strong typing system, including memory safety, type safety, and thread safety.

      Rust and Scade are both ‘high-integrity languages’, but with different use cases. Rust is a general-purpose language, that is well-suited for low-level drivers, middleware and performance-critical applications (like perception, sensor fusion). Scade is a domain-specific language for high-assurance real-time control applications.

      Rust and Scade can co-exist in the same application: Rust using Scade generated code, or using Rust code as imported code in a Scade model. For now, this can be done using the Rust Foreign Function Interface to interface C with Rust.



      One example of a Scade + Rust program architecture

      Want to learn more?

      In this article, we have shown that SCADE and Scade One provide a safe and secure solution that complies with the recent White House directive, in the same way Rust and Ada do. We also discussed how SCADE and Rust can be complementary and used to build different parts of the same embedded application.

      For more information about safety and cybersecurity with SCADE, you may wish to read this article on the Ansys Blog: Where Safety and Cybersecurity Intersect in Connected Vehicle Tech.

      To learn more about SCADE, please visit Embedded Software Development | Ansys.

      About the author



      Cédric Pasteur (LinkedIn) is a Senior Product Manager at Ansys. He has been working on Scade One, Ansys’ latest-generation model-based embedded software development product, since its inception. He specializes in programming language theory and its application to safe embedded systems.