Civil functional safety standards in a military context

Across the world there is an increasing tendency for civil functional safety standards to be adopted for military applications, For example,  commercial airworthiness (or, flight safety) standards such as ARP 4754A and DO-178C to be adapted and adopted for military projects. For example, there is nothing mandating military organisations to adopt the overarching ARP 4754A aircraft and systems certification  standard, the DO-178 software process standard, or its electronic hardware equivalent, DO-254. But the increasing popularity of such an approach suggests that those organisations see considerable benefit in applying the principles of DO-178C to their software development processes 

Here's why. 

7 Sections

AC-20 Reusable Software Components

First published in 2004, the FAA advisory circular “Reusable Software Components” (AC 20-148) provides many with substantial assistance for scaling the DO-178 mountain. According to that Advisory Circular, the developers of third party components which have achieved Reusable Software Component Certification (RSCC)  “…partially satisfy the applicable RTCA/DO-178 … objectives, while the integrator or applicant completes and shows the compliance for the integrated software package, systems aspects, and aircraft certification.”  

Learn more here of the perils of software reuse in general, of how RSCs have been successfully applied in safety critical applications to dateand of how the increased impact of security considerations might influence future RSCs.  

 

 

8 Sections

Tool qualification

If software tools are to automate significant numbers of DO-178C activities while producing evidential artefacts showing that objectives have been met, it is essential to ensure that those tools can be relied upon. 

Tool qualification is a vital part of to the certification process, and it is documented in the supplement Software Tool Qualification Considerations (DO-330) 

3 Sections

Verification of Executable Object Code from a Model (Version 1.0)

The introduction of RTCA/DO-331 Model based Development and Verification Supplement to DO-178C and DO-278A offers new opportunities to leverage the strengths of model based development under RTCA/DO-178C. The concept of model simulation for Executable Object Code (EOC) verification credit allows for the painstaking work of model verification to be reused to partially achieve EOC verification objectives. This document explores the conditions under which model verification can be used to partially satisfy EOC verification objectives and identifies areas which should be closely attended to in order to satisfy the regulatory requirements. 

7 Sections

LDRA Tool Qualification Packs A White Paper for the LDRA Tool Suite

RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification provides a mechanism to qualify tools for use in the development (including verification) of airborne software. RTCA/DO-330 defines the objectives by which tool qualification is measured. DO-178C specifies how to determine if a tool should be qualified, defines the applicable Tool Qualification Level (TQL), and then refers to RTCA/DO-330 Software Tool Qualification Considerations for the details on the actual qualification process. 

This document provides a background in tool qualification under RTCA/DO-178C and DO-330. It provides practical examples using Tool Qualification Support Packs (TQSPs) available from LDRA for the LDRA tool suite, with specific information on the objectives and activities included in the qualified function. 

7 Sections

Compliance consultancy: You’re not alone

Developing an aviation system or application that is compliant with challenging standards like ARP 4754A or DO-178C can be a daunting task 

For those taking on a compliant project for the first time, the complexity of the standard(s) and the overheads implied by that complexity can seem breathtakingly onerous. More experienced practitioners can be haunted by challenges faced in past projects, and question how they can learn from them to make future projects more cost and time effective.  

Small wonder that many development teams seek the reassurance that expert consultants can bring.  

4 Sections

Digital battlefield: The real final frontier?

The escalating complexity of the combat environment has seen the “Digital Battlefield” not only emerge as the primary mechanism for real-time situational awareness, but also embody technologies that can make other resources more effective – force multiplier”. Conventional forces including tanks, fighting vehicles, aircraft, rotorcrafts, artillery, combat vessels and convoy/support vehicles, all benefit from their interconnection within the digital battlefield. 

But security considerations are vitally important if the undoubted benefits of this approach are to be realized.  

4 Sections

The aerospace security framework and DO-326A

Today security has become a primary challenge in aerospace system development and certification. The aviation network, as well as the aircraft, are increasingly being connected to the internet (nose-to-tail) and other private networks, accessing connected services including weather forecasts, maintenance data, and high-speed broadband in the cabin to facilitate in-flight entertainment (IFE).  

Read how the Aerospace Security Framework is designed to the clear security implications (and hence safety implications) of these innovations. 

4 Sections

DO-178C in a military context

There is nothing obliging military organisations to adopt the overarching ARP 4754A process standard, the DO-178 software certification standard, or its hardware equivalent, DO-254. But the increasing popularity of such an approach suggests that those organisations see considerable benefit in applying the principles of DO-178C to their software development processes 

Here’s why. 

7 Sections

An introduction to FACE

Being locked into proprietary platforms or vendor specific open architectures has made the task of achieving supremacy in warfare technology no easier. These issues limit governmental ability to bring in third parties to compete or add new capabilities, resulting in expensive sole-source or single-bidder contract awards. By curbing long programme schedules and opening more integration options, the Future Airborne Capability Environment (FACE) initiative with its open systems architecture strategy can make a significant difference both commercially and technologically.  

4 Sections

DO-178C paragraph 6.4.4.2: Why Object Code Verification is essential

Uniquely amongst the functional safety standards across the sectors, DO-178C shines a spotlight on the potential for dangerous inconsistencies between developer intent and executable behaviour – and even then, it is not difficult to find advocates of workarounds with clear potential to leave those inconsistencies undetected.  

Learn here why the differences between source and object code can have devastating consequences for ANY critical application - irrespective of how such workaround approaches are excused.  

7 Sections

Object-Oriented Technology

As DO-178B was updated to DO-178C it was decided that these concerns, vulnerabilities, and subsequent additional objectives associated with object-oriented technologies would be addressed not by the original standard but rather a supplement, DO-332. This document provides an overview of how the concepts and key techniques of OO have been addressed by that supplement. 

4 Sections

Model-based development

As DO-178B was updated to DO-178C it was decided that the increasingly popular model-based development should be made available to compliant applications, and that they should be addressed by a supplement, DO-331, “Model-Based Development and Verification Supplement to DO-178C and DO-278A”. 

This document explains how the approach was adopted for specification models or design models take the place of high-level and low-level requirements respectivelythe extent to which model-based verification activities can be deployed, and where verification on the target is required.   

3 Sections

Object code verification and DO-178C objective A7-9

Level A software developers have been tasked with the verification of object code that is directly untraceable to source code since the introduction of RTCA/DO-178B in 1992. This type of object code consists of executable statements that “[introduce] branches or side effects that are not immediately apparent at the Source Code level”, including such things as compiler-generated array index boundary checks.  

Learn now DO-178C corrected what many saw as an oversight by including this so-called “hidden objective” in Table A-7 of Annex Amaking it more explicit in the Annex tables. And discover how DO-178C opened the door for using newer techniques for identifying and verifying object code not directly traceable to source code. 

5 Sections

An introduction to DO-178C’s structural coverage analysis objectives

Structural coverage analysis (SCA – also referred to as code coverage) is an important component of critical systems development.  

Structural coverage is used to identify which code structures and component interfaces have been exercised during the execution of requirements-based test proceduresfacilitating the empirical measurement of requirements-based test effectiveness. 

DO-178C mandates the use of coverage analysis for measuring completeness of testing. 

4 Sections

The technicalities of data coupling and control coupling

A structured design and functional decomposition approach has many merits. Breaking software down into clearly defined functional units or modules with unambiguous interfaces makes it easy to write, test and maintain. The net result is high quality software – but only if those the modules interact as expected.  That is why DO-178C requires that both data coupling and control coupling are shown to be in accordance with requirements.  

4 Sections

Meet data coupling and control coupling

A structured design and functional decomposition approach has many merits. Breaking software down into clearly defined functional units or modules with unambiguous interfaces makes it easy to write, test and maintain. The net result is high quality software – but only if those the modules interact as expected.  That is why DO-178C requires that both data coupling and control coupling are shown to be in accordance with requirements.  

4 Sections

DO-178B to DO-178C: The evolution of a standard

Towards the end of the noughties, avionics manufacturers were facing geometric growth in software size and complexity and losing control of project schedules and budgets. Consequently, the Radio Technical Commission for Aeronautics (RTCA) and the European Organisation for Civil Aviation Equipment (EUROCAE) looked to address software development challenges through the introduction of DO-178C – a standard that embraced the contemporary technologies and methodologies necessary to achieve these aims. 

Here we reflect on the thinking that gave rise to DO-178C, and how it built upon its successful DO-178B predecessor. 

4 Sections

LDRA tool suite® and PTC® Windchill® integration

The mission for PTC Windchill software is to help innovative industries to advance the development, governance and maintenance of software by providing a unified solution for requirements, quality, and application lifecycle management. The integration with the LDRA tool suite with its concept of traceable, bidirectionally linked work items extends Windchill’s enterprise capabilities to embedded software analysis and testing. 

Learn how the combined solution enables users to trace between requirements and source code analyses and tests, leveraging the LDRA tool suite to perform static and dynamic analysis, and reflecting the outcomes of those analyses in the Windchill user interface. 

 

5 Sections

DO-178C: Get on a High with your Software Development

DO-178C covers the complete software lifecycle: planning, development and integral processes to ensure correctness and robustness in the software. The integral processes include software verification, software quality assurance, configuration management assurance and certification liaison with the regulatory authorities. 

This document explains that although the standards do not oblige developers to use analysis, test, and traceability tools in their work, such tools improve efficiency in all but the most trivial projects to the extent that they have a significant part to play in the achievement of the airworthiness objectives for airborne software throughout the development lifecycle. 

7 Sections

Why worry about hacking?

In recent years, sophisticated and daring cyberattacks have grabbed the headlines and the attention of the public. Both Miller and Valasek’s famous attack on a Chrysler Jeep as referenced in their 2015 paper “Remote Exploitation of an Unaltered Passenger Vehicle and a separate, sophisticated attack on the Ukraine power grid that same year involved highly motivated, organized, qualified and professional individuals with considerable resources at their disposal. 

It would be easy to conclude that all hackers fit that description. But in fact, hacking is easy, requires very little technical skill, and is widely seen as an easy way to make money by the unscrupulous. Here’s why that should concern anyone developing a connected application or device.    

5 Sections

Verification of Safety-Related Control System Software in Compliance with ISO 13849:2015

There is a confusing wealth of standards relating to machine control systems. This document helps clarify the role of IEC 13849-1 and explains its relationship with IEC/ISO 17305, IEC 62061 and IEC 61508.

6 Sections

Applying IEC 62443-4-1 to Industrial Automation Control Systems

IEC 62443-4:2018 specifies the requirements for the secure development of systems used in industrial control and automation, with part 1 describing the product development requirements. Learn how verification and validation plays an important role in the IEC 62443-4-1 process, and discusses the testing techniques required to comply with the standard’s recommendation for requirement based testing.

4 Sections

Getting to grips with MISRA C:2012

MISRA C is a coding standard appropriate for the development of critical application code, including code for security- and safety-critical applications. LDRA have been influential in its creation and ongoing development, and has had strong representation on the MISRA C working group throughout its evolution. This introduction reflects that unique insight into the creation of the standard, and into the incremental changes resulting from a policy of continuous improvement.

5 Sections

Automate ISO/SAE DIS 21434 compliance – when the time is right

It is welcome news that ISO / SAE 21434 automotive cybersecurity standard has reached the Draft International Standard (DIS) stage. LDRA is committed to fully supporting the standard with enhancements to the LDRA tool suite® for Automotive as dictated by formal release of the standard, but advises caution until then. Here's why.

The End of the Develop-First, Test-Later Approach to Software Development

The traditional approach to secure software development is mostly a reactive one – develop the software and then use penetration, fuzz and functional test to expose any weaknesses. In isolation, however, that is not good enough to comply with a functional safety standard such as DO-178C (in the aerospace sector), IEC 62304 (medical devices) or ISO 26262 (automotive). These demand that security factors with a safety implication are considered from the outset, because a safety-critical system cannot be safe if is not secure.

4 Sections

SAST - Static Analysis/Application Security Test

Static Analysis (or Application) Security Test tools - SAST tools for short - provide the earliest possible insight into the security of an embedded application by scanning the source code. SAST is available as soon as there is source code and by building it into the Secure Software Development LifeCycle (SSDLC), vulnerabilities can be detected even before the build stage is reached.

3 Sections

Requirements Traceability

Best practice suggests that that bidirectional traceability between those requirements, software design artefacts, source code and tests should be established. Such an approach not only ensures that all security requirements are fulfilled, but also that there is no surplus code offering aggressors “back door” access to critical code.

3 Sections

Pen testing and the Secure Software Development Lifecycle

Penetration (or pen) testing is an example of a black box DAST (Dynamic Application/Analysis Security Test). It involves software security experts trying to exploit application code either manually or automatically. Although a traditional approach to software security and one which provides no direct insight into the application source code, pen testing remains relevant despite the advent of the "shift left" paradigm. Here's why it remains a key component of the Secure Sofware Development Lifecycle (SSDLC).

3 Sections

Securing the Industrial Internet of Things

The “Industrial Internet of Things” (IIoT) is a virtual connection of data from people, processes, and things. It promises a world of convenience, efficiency, and economic opportunity to all manufacturing industry. But history has taught us that where society makes changes for the benefit of the majority, we must always be wary of the “touch of human weakness” - opportunists amongst us who will seek to disrupt it or to take dishonest advantage of it. Learn how secure application code is a vital component of any secure IIoT application, including IIRA and RAMI 4.0 compliant applications.

8 Sections

Endpoints and IOT security

Search in any browser for “IoT security”, and the results will most likely refence security frameworks, IoT and OT monitoring, data protection, hardware devices, and middleware. But amidst all of this very useful technology it is easy to overlook the endpoints – the physical computing devices that perform a function or task as a part of an internet connected product or service, such as wearable fitness devices, industrial control systems, automotive telematics units, and home heating thermostats. Secure endpoint software development is a key component of any defence in depth strategy.

2 Sections

Defence in depth

Defence in Depth describes an approach to security in which a series of defensive mechanisms are layered in order to protect valuable data and information, such that if one mechanism fails, another can be relied upon to thwart an attack. Learn more of the role of secure application code as part of a defence in depth strategy.

3 Sections

Embedded Systems and Security Maturity Models

Although there are growing numbers of standards offering guidance on security issues, few provide an adequate measure of the security measures themselves. Security Maturity Models enable communities to evaluate their current status from the very start of the development lifecycle, supporting the "shift left" paradigm. They provide a framework for a programme to improve security posture, and provide a framework for them to design a programme to improve their security posture, and are sufficiently adaptable to be applicable to both embedded and enterprise computing alike.

5 Sections

CERT Secure Coding Practices

Recognised as a trusted, authoritative organisation dedicated to improving the security and resilience of computer systems and networks, the CERT (Computer Emergency Readiness Team) Division of the Software Engineering Institute (SEI), ​CERT have nominated a total of 12 key secure coding practices – a “top ten”, more recently supplemented by two “bonus practices”. Adherence to these practices is key to the successful implementation of the secure software development lifecycle (SSDLC).

7 Sections

Blaster Worm: A vulnerability case study

One of the most high-profile security threats in recent times was the Blaster worm which was first seen on July 14, 2003, infected at least 100,000 Microsoft windows systems, and cost millions in damage. According to some commentators, the W32.Blaster worm may have contributed to the cascading effect of the blackout in the US north-east that year.

This paper explains how SAST (Static Analysis/Application Security Test) tools can help you find such security vulnerabilities early in the secure software development lifecycle (SSDLC), minimizing opportunities for bad actors when the software is deployed.

5 Sections

SSDLC: A proactive approach to secure software development

Connected systems underpin the drive for technological development in many domains such as aerospace, defense, automotive, healthcare and industrial control. When networked together, intelligent electronic devices form smart systems that impact almost all aspects of our lives. Security is critical, and cannot be an afterthought. To be optimal it must be designed in - the embodiment of the "shift left" paradigm.

4 Sections

DAST - Dynamic Analysis/Application Security Test

Dynamic Analysis (or Application) Security Test - DAST for short is a key component of the secure software development lifecycle (SSDLC). It provides evidence of adherence to security requirements and a rigorous and thorough test of potential vulnerabilities. Unlike static analysis, it exercises part or all of the application, usually on the target device for which it was developed.

6 Sections

Addressing your insecurities with CERT C

Secure coding standards make a vital contribution to any SAST regime, and represent a key component of any successful secure software development lifecycle (SSDLC). Learn how best to apply the CERT C Coding Standard, which consists of a set of guidelines designed to assist in the development of safe, reliable, and secure systems, and was developed by the renowned Computer Emergency Response Team (CERT) division of the Software Engineering Institute (SEI).

5 Sections

ISO 26262 Technical Overview

There is an ever-widening range of automotive electrical and/or electronic (E/E/PE) systems such as adaptive driver assistance systems, anti-lock braking systems, steering and airbags. Their increasing levels of integration and connectivity provide almost as many challenges as their proliferation, with non-critical systems such as entertainment systems sharing the same communications infrastructure as steering, braking and control systems. Read how the resulting need for exacting functional safety development processes is fulfilled by ISO 26262, from requirements specification, design, implementation, integration, verification, validation, and through to configuration.

4 Sections

An Introduction to Automated MISRA C:2012 Analysis and Review

MISRA C has always been designed to support the development of all critical applications. These include functionally safe applications in accordance with standards such as ISO 26262, IEC 61508 and DO-178C, and secure applications as part of a SAST regime. Although it has become much more user-friendly in recent years, enforcing is manually would be impossibly difficult and time-consuming. This video explains how automated code review - an important contributor to the "shift left" paradigm - is initiated, and how reported violations can be understood and corrected.

Checking for MISRA C:2004 and MISRA C++:2008 Compliance

MISRA coding standards has always been designed to support the development of all critical applications. These include functionally safe applications in accordance with standards such as ISO 26262, IEC 61508 and DO-178C, and secure applications as part of a SAST regime. Although it has become much more user-friendly in recent years, enforcing is manually would be impossibly difficult and time-consuming. This video explains how automated code review is initiated, and how reported violations can be understood and corrected.

Leveraging Automated Code Review with C++

The C++ language includes features that are prone to error - a problem for any functionally safe or secure system development. To counter that, "coding standards" or "language subsets" can be used in accordance with a functional safety standard (ISO 26262, IEC 61508, DO-178C...) or as part of a SAST regime to reduce the opportunity for mistakes by restricting the use of those features. Referencing the JSF ++ and MISRA C++:2008 subsets of the C++ language, this presentation gives a practical overview of how deviations from a standard can be identified and addressed using an automated code review process.

Automated Code Review with C

The C language includes features that are prone to error - a problem for any functionally safe or secure system development. To counter that, "coding standards" or "language subsets" can be used in accordance with a functional safety standards (ISO 26262, IEC 61508, DO-178C...) or as part of a SAST regime to reduce the opportunity for mistakes by restricting the use of those features. Referencing the MISRA C:2004 subset of the C language, this presentation gives a practical overview of how deviations can be identified and addressed using an automated code review process, how baselines can be used to monitor progress, and how a custom coding standard can be created.

IBM Rational DOORS: Automated Traceability Between Requirements, Source Code, and Tests

The IBM Rational DOORS ALM tool provides facilities for the careful management and monitoring of all aspects of software development and completing the phases of design, development, testing, deployment, and ongoing enhancements. However, ALM tools in general rely on manual intervention to collate information on code development, verification and validation. This overview presentation shows how the collation of that information can be automated, making for a more seamless and less error prone solution.

Siemens Polarion REQUIREMENTS: Automated Traceability Between Requirements, Source Code, and Tests

The Siemens Polarion REQUIREMENTS ALM tool provides facilities for the careful management and monitoring of all aspects of software development and completing the phases of design, development, testing, deployment, and ongoing enhancements. However, ALM tools in general rely on manual intervention to collate information on code development, verification and validation. This overview presentation shows how the collation of that information can be automated, making for a more seamless and less error prone solution.

Jama Connect: Automated Traceability Between Requirements, Source Code, and Tests

The Jama Connect ALM tool provides facilities for the careful management and monitoring of all aspects of software development and completing the phases of design, development, testing, deployment, and ongoing enhancements. However, ALM tools, in general, rely on manual intervention to collate information on code development, verification, and validation. This detailed presentation shows how the collation of that information can be automated, making for a more seamless and less error-prone solution.

Automated Dynamic Analysis and Unit Testing with the IAR Embedded Workbench

Functional safety standards (ISO 26262, IEC 61508, DO-178C etc.) often require that the test environment for software unit (low-level), integration and system testing reflects the target environment. Best practice in the development of secure applications for all DAST techniques would echo that recommendation, and in both cases most thorough way of achieving it is to perform the tests on the target itself. This detailed presentation shows how an automated integrated environment provides an efficient and effective path to the achievement of that objective, where the development enviroment used with the target is the IAR Embedded Workbench.

Automated Dynamic Analysis and Unit Testing with TI Code Composer Studio V5

Functional safety standards (ISO 26262, IEC 61508, DO-178C etc.) often require that the test environment for software unit (low-level), integration and system testing reflects the target environment. Best practice in the development of secure applications for all DAST techniques would echo that recommendation, and in both cases most thorough way of achieving it is to perform the tests on the target itself. This detailed presentation shows how an automated integrated environment provides an efficient and effective path to the achievement of that objective, where the development enviroment used with the target is the TI Code Composer Studio v5.

SAE J3061 and ISO 26262? They're Made for Each Other

SAE J3061 provides an engineering process to design and build cybersecurity into vehicle systems in a comprehensive and systematic way, to monitor for and respond to incidents in the field, and to address vulnerabilities in service and operation. This document describes how that process relates to the ISO 26262 functional safety standard in the context of automotive software systems

13 Sections

Automated Static Analysis, Dynamic Analysis and Unit Testing with the Eclipse-Based TI Code Composer Studio V6

Functional safety standards (ISO 26262, IEC 61508, DO-178C etc.) often require that the test environment for software unit (low-level), integration and system testing reflects the target environment. Best practice in the development of secure applications for all DAST techniques would echo that recommendation, and in both cases most thorough way of achieving it is to perform the tests on the target itself. This detailed presentation shows how an automated integrated environment provides an efficient and effective path to the achievement of that objective, where the development enviroment used with the target is the TI Code Composer Studio v6.

Page 1 of 2

No cookie

Pen
facilisis pulvinar dictum lectus Donec amet, porta.