Beyond DO-178: Building Secure Solutions for Future Aviation Systems

The triple-threat of RTI Connext DDS, DDC-I Deos, and wolfSSL FIPS 140-2 certified cryptography provide a perfect union that allows avionics system developers to meet mission-critical communication security goals.

RTI Connext DDS is the software connectivity framework designed to meet the demanding requirements of critical airborne systems requiring low latency, high reliability, scalability, security and COTS DO-178C DAL A certification evidence. RTI Connext TSS is the first certified, conformant FACE™ Transport Services Segment (TSS), enabling rapid interoperability of FACE system components and networked platforms.

DDC-I’s Deos is a field proven, safety-critical, avionics RTOS that is used to host a multitude of flight critical functions, such as air data computers, air data inertial reference units, cockpit video, displays and flight instrumentation, flight management systems, engine management, and many more. Built from the ground up for safety-critical applications, Deos is the only certifiable time- and space-partitioned COTS RTOS that has been created using RTCA DO-178, Level A processes from the very first day of its product development. Deos’ unique modular design and verification evidence provides the easiest, lowest cost path to DO-178C DAL A certification, the highest level of safety criticality.

The wolfSSL embedded SSL library is a lightweight, portable, C language-based SSL/TLS library targeted at embedded and RTOS environments and therefore well suited for connected avionics applications. Featuring FIPS 140-2 certified cryptography, the compact library supports industry standards up to TLS 1.3 and DTLS 1.2, is up to 20 times smaller than OpenSSL, offers a simple API, provides an OpenSSL compatibility layer, and includes OCSP and CRL support.

Join us as we explore these combined solutions for building secure future aviation systems!

[bennguyen]

Are most big companies using the SCRUM / Kanban methodology (or framework) to satisfy the AGILE/Waterfall/V-Model philosophy (SDLC) ?

I'd like to move away from a rapid-prototype environment to something more formal in order to develop high quality/safe products containing embedded software.. for ANY industry.. Aerospace (like Lockhead's SEAL Level X, Boeing, DDPMAS, DAL A to E etc), Medical or Nuclear industries.. even Automotive. I'd love to see a trivial project example that shows all the steps and outputs.

For example, assuming I document the process on how the code is generated, what constitutes proof that it's safe?
Static Analysis?
Code Coverage - Statement (Level C), Decision (Level B), MCDC (Level A)?
Who defines the unit tests?

I imagine there are differences between the industries..
FAA : DO-178X, DO 331, ARP4754A , ED-12C
FDA : 13485, ISO14971, IEC 62304, SaMD and
DOE Nuclear : 414.1x,
(Automotive : 26262)

but what are the typical tools/software needed, and the typical document/artifacts in the various stages of the software life cycle?

I saw a good video by CEMILAC Education Program "Airborne Software Development & Certification Process" and it's a bit overwhelming:
Requirement Management - (IBM Ration) DOORS, JAMA, Xebrio, rmtoo florath, doorstop-dev / doorstop, reqview, STELL
Static Structural Source Code Analysis - Parasoft, PolySpace, CodeSonar, horusec, SonarCloud, veracode PREFast, TBrun, LDRA
Dynamic Analysis / Modified Condition/Decision Coverage (MC/DC) - VectorCAST, RapiTest
Traceability Tools: Reqtify, Polarion, McCabe
Configuration Management / Storage and Version Control System - Git, SourceSafe, Mercurial, MS TFS, ClearCase
QA / ALM- Helix ALM for Managing Artifacts, Establishing Traceability, Documenting / Enforcing Processes, etc
(I)V&V / Unit Test Automation - VectorCAST, LDRA Testbed, Mathworks Simulink DO Qualification Kit
Continuous Integration / CD - Continuous Delivery/Deployment - Jenkins, Bamboo, or GitLab CI/CD

And what is the general attitude towards open source software (ex. FreeRTOS) and code-generation tools (ex. ST's Cube MX)?

Also, how do CPLD and FPGAs fit in to the embedded software picture.. since not exactly software nor hardware, since they are programmable devices written in an programming language like VHDL, (system) verilog, Amaranth HDL ? How would DO-254 apply to HDLs?