This document provides an overview of DO-178B, the standard used to ensure safety in avionics software development. It discusses key aspects of DO-178B including the 5 software safety levels, objectives for each level, the software lifecycle processes of planning, development, verification, and certification. It also briefly outlines the future of DO-178C, which incorporates modern techniques like model-based design, tool qualification, and formal methods.
Case Study on IV&V of the Landing Gear ControllerOak Systems
RUSTOM II is a Medium-Altitude Long-Endurance (MALE) Unmanned Aerial Vehicle (UAV) with an endurance of 24 hours and the ability to fly up to 25000 feet altitude.
It has multiple payload capabilities to support both daytime and nighttime operations.
The retractable landing gear system consists of dual redundant microcontrollers. The Landing Gear Controller (LGC) is required to execute and monitor the retraction, deployment, and brake sequence of the landing gear based on the command received from the Flight Control Computer (RFCC). The LGC is connected to the RFCC through the MIL1553B interface.
The RFCC acts as a bus controller (BC), and the LGC acts as a remote terminal (RT), with software-programmable RT addresses 22 (active) and 23 (standby).
However, provision is made to set the RT addresses through hardware.
LGC has dual redundant 32-bit microcontrollers in the main/hot standby configuration. When the main controller fails, the hot standby controller executes the operations.
The main controller and standby controller are interfaced via a cross-channel data link (CCDL) asynchronous RS422 interface.
LGC is connected to the RFCC via the 1553B bus for receiving commands, to the nose and main landing gears through analog input via ADC and duplex discrete I/O, and to the hydraulic motor pump via analog input and discrete output.
The LGC software performs the following functionalities:.
Perform modes of operation like retraction, deployment, brake, emergency deployment, and emergency brake based on the RFCC command.
Activate the landing gear subsystem assemblies like the hydraulic power pack, retraction, deployment, brake, bypass, and emergency valves.
Monitor the subsystem assembly, like wheel speed, weight on the wheel, hydraulic pressure, valve pressure, and actuator end-limit switches, and post the status to the RFCC.
Perform Power on Self Test (POST), Initiated Pre-flight Built-In Test (PBIT), and Continuous Built-In Test (CBIT) functionalities.
Output the parameters to telemetry.
Understanding DO-178: Importance and How It Affects Your CompanyAversan Inc.
Learn DO-178: Why is it important? How can it affect your company? These questions and more will be answered in this presentation, including information regarding the purpose of DO-178, Design Assurance Levels (DAL), objectives, and integral processes.
Questions? Email bd@aversan.com for more information.
Case Study on IV&V of Attitude and Heading Reference SystemOak Systems
The Attitude and Heading Reference System provides attitude, heading, linear accelerations, and angular rate data to the interfacing system, i.e., the ADIU.
In addition to these parameters, the system shall also provide built-in test information to the ADIU simultaneously.
The system takes external magnetometer data frames and air data frames from the ADIU and uses these data to aid the inertial data.
The system also supports maintenance mode, in which it performs the compass swing procedure for the calibration of the internal and external magnetometers. The system also performs an in-situ firmware upgrade in the maintenance mode, among other functions.
It has both an inertial measurement unit and a navigational unit. Both perform POST and CBIT independently as a part of their health monitoring. Both communicate through a UART interface for the transfer of data using a packet-based data protocol with error checking. A second UART interface is provided for redundancy.
• Overall 5 years of IT Experience which include experience in the field of RBT in HSIT (Hardware software integration testing), SWI (Software integration testing), UT (Unit testing) Experienced in the Software Verification activities for safety critical systems in compliance with DO-178B standards
Case study - IV&V of Standby Engine InstrumentOak Systems
Presenting a Case study on Software Verification & Validation (IV&V) for a subsystem of a Defence Helicopter. The IV&V was carried out in accordance with the RTCA DO178B DAL B guidelines. With over 2 decades of strong experience, Oaksys was chosen to carry out the full lifecycle IV&V of the said subsystem. This is one of many such projects where Oaksys was responsible for conducting software IV&V and Testing.
Case Study on IV&V of the Landing Gear ControllerOak Systems
RUSTOM II is a Medium-Altitude Long-Endurance (MALE) Unmanned Aerial Vehicle (UAV) with an endurance of 24 hours and the ability to fly up to 25000 feet altitude.
It has multiple payload capabilities to support both daytime and nighttime operations.
The retractable landing gear system consists of dual redundant microcontrollers. The Landing Gear Controller (LGC) is required to execute and monitor the retraction, deployment, and brake sequence of the landing gear based on the command received from the Flight Control Computer (RFCC). The LGC is connected to the RFCC through the MIL1553B interface.
The RFCC acts as a bus controller (BC), and the LGC acts as a remote terminal (RT), with software-programmable RT addresses 22 (active) and 23 (standby).
However, provision is made to set the RT addresses through hardware.
LGC has dual redundant 32-bit microcontrollers in the main/hot standby configuration. When the main controller fails, the hot standby controller executes the operations.
The main controller and standby controller are interfaced via a cross-channel data link (CCDL) asynchronous RS422 interface.
LGC is connected to the RFCC via the 1553B bus for receiving commands, to the nose and main landing gears through analog input via ADC and duplex discrete I/O, and to the hydraulic motor pump via analog input and discrete output.
The LGC software performs the following functionalities:.
Perform modes of operation like retraction, deployment, brake, emergency deployment, and emergency brake based on the RFCC command.
Activate the landing gear subsystem assemblies like the hydraulic power pack, retraction, deployment, brake, bypass, and emergency valves.
Monitor the subsystem assembly, like wheel speed, weight on the wheel, hydraulic pressure, valve pressure, and actuator end-limit switches, and post the status to the RFCC.
Perform Power on Self Test (POST), Initiated Pre-flight Built-In Test (PBIT), and Continuous Built-In Test (CBIT) functionalities.
Output the parameters to telemetry.
Understanding DO-178: Importance and How It Affects Your CompanyAversan Inc.
Learn DO-178: Why is it important? How can it affect your company? These questions and more will be answered in this presentation, including information regarding the purpose of DO-178, Design Assurance Levels (DAL), objectives, and integral processes.
Questions? Email bd@aversan.com for more information.
Case Study on IV&V of Attitude and Heading Reference SystemOak Systems
The Attitude and Heading Reference System provides attitude, heading, linear accelerations, and angular rate data to the interfacing system, i.e., the ADIU.
In addition to these parameters, the system shall also provide built-in test information to the ADIU simultaneously.
The system takes external magnetometer data frames and air data frames from the ADIU and uses these data to aid the inertial data.
The system also supports maintenance mode, in which it performs the compass swing procedure for the calibration of the internal and external magnetometers. The system also performs an in-situ firmware upgrade in the maintenance mode, among other functions.
It has both an inertial measurement unit and a navigational unit. Both perform POST and CBIT independently as a part of their health monitoring. Both communicate through a UART interface for the transfer of data using a packet-based data protocol with error checking. A second UART interface is provided for redundancy.
• Overall 5 years of IT Experience which include experience in the field of RBT in HSIT (Hardware software integration testing), SWI (Software integration testing), UT (Unit testing) Experienced in the Software Verification activities for safety critical systems in compliance with DO-178B standards
Case study - IV&V of Standby Engine InstrumentOak Systems
Presenting a Case study on Software Verification & Validation (IV&V) for a subsystem of a Defence Helicopter. The IV&V was carried out in accordance with the RTCA DO178B DAL B guidelines. With over 2 decades of strong experience, Oaksys was chosen to carry out the full lifecycle IV&V of the said subsystem. This is one of many such projects where Oaksys was responsible for conducting software IV&V and Testing.
When created early in the product development lifecycle, a trace matrix can do more than just help you gain FDA approval for your device. Unfortunately, many companies create the matrix sporadically during a project, mainly right before regulatory submission—too late to capture the benefits a well-maintained matrix can deliver.
During this recorded webinar, guest speaker Steve Rakitin, President of Software Quality Consulting, discussed five of the benefits gained by maintaining a matrix throughout the project. A software engineer with more than 20 years of experience in the medical device industry, Steve explains how a trace matrix can help you:
- Plan and estimate testing and validation needs
- Ensure all requirements are implemented
- Verify that all requirements have been tested
- Manage change throughout product development
- Provide evidence that hazard mitigations are implemented and validated
Beyond FDA Compliance Webinar: 5 Hidden Benefits of Your Traceability MatrixSeapine Software
When created early in the product development lifecycle, a trace matrix can do more than just help you gain FDA approval for your device. Unfortunately, many companies create the matrix sporadically during a project, mainly right before regulatory submission—too late to capture the benefits a well-maintained matrix can deliver.
During this recorded webinar, guest speaker Steve Rakitin, President of Software Quality Consulting, discussed five of the benefits gained by maintaining a matrix throughout the project. A software engineer with more than 20 years of experience in the medical device industry, Steve explains how a trace matrix can help you:
- Plan and estimate testing and validation needs
- Ensure all requirements are implemented
- Verify that all requirements have been tested
- Manage change throughout product development
- Provide evidence that hazard mitigations are implemented and validated
Webinar | APM Best Practices - Effectively managing the safety lifecycleStork
Effectively managing the safety lifecycle requires teamwork between multiple disciplines, departments and companies, but it shouldn’t require multiple solutions. See how you can consolidate the entire safety lifecycle into a streamlined solution ensuring risk is reduced, instrumented systems are available and compliance requirements are met. The “cradle to grave” lifecycle approach that is enabled by the APM Safety work process provides visibility across the organization to what teams are doing, and how well their doing it.
In this third webinar in a series about APM, Stork, SOCAR Turkey and GE Digital share their insights on process safety best practices, from various perspectives: the process, the solution and the culture.
Case Study_IV&V of AutomaticFlightControlPanel.pdfOak Systems
3-axis (Pitch, Roll, and Yaw) simplex and 4-axis AFCS (Pitch, Roll, and Yaw & Collective) digital Automatic Flight Control System (AFCS) on LUH are used to provide stability, controllability, and autopilot modes for ease of flying. The AFCS consists of an Automatic Flight Control Computer (AFCC) and an Automatic Flight Control Panel (AFCP). The AFCC is the core of the AFCS.
The Automatic Flight Control Panel (AFCP) is the main man-machine interface between the pilot and AFCC for control commands, status indicators, and alphanumeric displays of AFCS functions. The AFCP software receives commands from the panel push-button control switch, transmits these commands to the AFCC through the ARINC429 channel, and receives the commands from the AFCC through the ARINC429 channel. The received ASCII data is shown on an alphanumeric display.
In diesem Vortrag auf dem Vortrag auf dem YAVEON Kundentag 2014 stellt Rainer Elvermann, Geschäftsführer cbprocess GmbH & Co. KG, das "context based process management" vor. Anhand konkreter Beispiele aus komplexen Branchen (Luft- & Raumfahrt, Automotive, Forschungsschiffe, Bauwesen) spricht Herr Elvermann über aktuelle Erfahrungen mit Business Process Management im allgemeinen und dem verwendeten Tool, process4.biz, im besonderen.
Using Doors® And Taug2® To Support A Simplifiedcbb010
In order to become a market leader, it is imperative that all stakeholders (customers, financial sponsors, developers and testers) be aware of the customer’s needs as captured in the requirements of the products and/or services that are to be produced. This is especially so within both large and small globally distributed companies since the product development organizations often are separated by geography, time and communications. An efficient way to eliminate these potential issues is to develop a common and intuitive requirements management process, which can be deployed across the product development lifecycle. The object of developing a Common Simplified Requirements Management Process is to improve customer satisfaction, eliminate escaping defects and reduce the cost of the development lifecycle. This paper describes the problems of using localised procedures and how these problems can be eliminated by implementing a common requirements management process that is intuitive, scalable and deployed across the System Development Lifecycle. This process has been supported by the industry leading DOORS tool and more recently by the TauG2 tool. An auxiliary benefit of deploying this process is that the process was developed in compliance with standardized methods of documenting and tracing requirements as expected by TL9000 and CMM/CMMI. The net benefits of this simplified requirements process include: increased customer satisfaction due to systems being developed in accordance with the customer’s needs as captured in the requirements, compliance with industry acknowledged process standards and improved cost of quality by eliminating duplication of process maintenance since a common process has been deployed across the development organization.
Hierarchical Digital Twin of a Naval Power SystemKerry Sado
A hierarchical digital twin of a Naval DC power system has been developed and experimentally verified. Similar to other state-of-the-art digital twins, this technology creates a digital replica of the physical system executed in real-time or faster, which can modify hardware controls. However, its advantage stems from distributing computational efforts by utilizing a hierarchical structure composed of lower-level digital twin blocks and a higher-level system digital twin. Each digital twin block is associated with a physical subsystem of the hardware and communicates with a singular system digital twin, which creates a system-level response. By extracting information from each level of the hierarchy, power system controls of the hardware were reconfigured autonomously. This hierarchical digital twin development offers several advantages over other digital twins, particularly in the field of naval power systems. The hierarchical structure allows for greater computational efficiency and scalability while the ability to autonomously reconfigure hardware controls offers increased flexibility and responsiveness. The hierarchical decomposition and models utilized were well aligned with the physical twin, as indicated by the maximum deviations between the developed digital twin hierarchy and the hardware.
When created early in the product development lifecycle, a trace matrix can do more than just help you gain FDA approval for your device. Unfortunately, many companies create the matrix sporadically during a project, mainly right before regulatory submission—too late to capture the benefits a well-maintained matrix can deliver.
During this recorded webinar, guest speaker Steve Rakitin, President of Software Quality Consulting, discussed five of the benefits gained by maintaining a matrix throughout the project. A software engineer with more than 20 years of experience in the medical device industry, Steve explains how a trace matrix can help you:
- Plan and estimate testing and validation needs
- Ensure all requirements are implemented
- Verify that all requirements have been tested
- Manage change throughout product development
- Provide evidence that hazard mitigations are implemented and validated
Beyond FDA Compliance Webinar: 5 Hidden Benefits of Your Traceability MatrixSeapine Software
When created early in the product development lifecycle, a trace matrix can do more than just help you gain FDA approval for your device. Unfortunately, many companies create the matrix sporadically during a project, mainly right before regulatory submission—too late to capture the benefits a well-maintained matrix can deliver.
During this recorded webinar, guest speaker Steve Rakitin, President of Software Quality Consulting, discussed five of the benefits gained by maintaining a matrix throughout the project. A software engineer with more than 20 years of experience in the medical device industry, Steve explains how a trace matrix can help you:
- Plan and estimate testing and validation needs
- Ensure all requirements are implemented
- Verify that all requirements have been tested
- Manage change throughout product development
- Provide evidence that hazard mitigations are implemented and validated
Webinar | APM Best Practices - Effectively managing the safety lifecycleStork
Effectively managing the safety lifecycle requires teamwork between multiple disciplines, departments and companies, but it shouldn’t require multiple solutions. See how you can consolidate the entire safety lifecycle into a streamlined solution ensuring risk is reduced, instrumented systems are available and compliance requirements are met. The “cradle to grave” lifecycle approach that is enabled by the APM Safety work process provides visibility across the organization to what teams are doing, and how well their doing it.
In this third webinar in a series about APM, Stork, SOCAR Turkey and GE Digital share their insights on process safety best practices, from various perspectives: the process, the solution and the culture.
Case Study_IV&V of AutomaticFlightControlPanel.pdfOak Systems
3-axis (Pitch, Roll, and Yaw) simplex and 4-axis AFCS (Pitch, Roll, and Yaw & Collective) digital Automatic Flight Control System (AFCS) on LUH are used to provide stability, controllability, and autopilot modes for ease of flying. The AFCS consists of an Automatic Flight Control Computer (AFCC) and an Automatic Flight Control Panel (AFCP). The AFCC is the core of the AFCS.
The Automatic Flight Control Panel (AFCP) is the main man-machine interface between the pilot and AFCC for control commands, status indicators, and alphanumeric displays of AFCS functions. The AFCP software receives commands from the panel push-button control switch, transmits these commands to the AFCC through the ARINC429 channel, and receives the commands from the AFCC through the ARINC429 channel. The received ASCII data is shown on an alphanumeric display.
In diesem Vortrag auf dem Vortrag auf dem YAVEON Kundentag 2014 stellt Rainer Elvermann, Geschäftsführer cbprocess GmbH & Co. KG, das "context based process management" vor. Anhand konkreter Beispiele aus komplexen Branchen (Luft- & Raumfahrt, Automotive, Forschungsschiffe, Bauwesen) spricht Herr Elvermann über aktuelle Erfahrungen mit Business Process Management im allgemeinen und dem verwendeten Tool, process4.biz, im besonderen.
Using Doors® And Taug2® To Support A Simplifiedcbb010
In order to become a market leader, it is imperative that all stakeholders (customers, financial sponsors, developers and testers) be aware of the customer’s needs as captured in the requirements of the products and/or services that are to be produced. This is especially so within both large and small globally distributed companies since the product development organizations often are separated by geography, time and communications. An efficient way to eliminate these potential issues is to develop a common and intuitive requirements management process, which can be deployed across the product development lifecycle. The object of developing a Common Simplified Requirements Management Process is to improve customer satisfaction, eliminate escaping defects and reduce the cost of the development lifecycle. This paper describes the problems of using localised procedures and how these problems can be eliminated by implementing a common requirements management process that is intuitive, scalable and deployed across the System Development Lifecycle. This process has been supported by the industry leading DOORS tool and more recently by the TauG2 tool. An auxiliary benefit of deploying this process is that the process was developed in compliance with standardized methods of documenting and tracing requirements as expected by TL9000 and CMM/CMMI. The net benefits of this simplified requirements process include: increased customer satisfaction due to systems being developed in accordance with the customer’s needs as captured in the requirements, compliance with industry acknowledged process standards and improved cost of quality by eliminating duplication of process maintenance since a common process has been deployed across the development organization.
Hierarchical Digital Twin of a Naval Power SystemKerry Sado
A hierarchical digital twin of a Naval DC power system has been developed and experimentally verified. Similar to other state-of-the-art digital twins, this technology creates a digital replica of the physical system executed in real-time or faster, which can modify hardware controls. However, its advantage stems from distributing computational efforts by utilizing a hierarchical structure composed of lower-level digital twin blocks and a higher-level system digital twin. Each digital twin block is associated with a physical subsystem of the hardware and communicates with a singular system digital twin, which creates a system-level response. By extracting information from each level of the hierarchy, power system controls of the hardware were reconfigured autonomously. This hierarchical digital twin development offers several advantages over other digital twins, particularly in the field of naval power systems. The hierarchical structure allows for greater computational efficiency and scalability while the ability to autonomously reconfigure hardware controls offers increased flexibility and responsiveness. The hierarchical decomposition and models utilized were well aligned with the physical twin, as indicated by the maximum deviations between the developed digital twin hierarchy and the hardware.
CFD Simulation of By-pass Flow in a HRSG module by R&R Consult.pptxR&R Consult
CFD analysis is incredibly effective at solving mysteries and improving the performance of complex systems!
Here's a great example: At a large natural gas-fired power plant, where they use waste heat to generate steam and energy, they were puzzled that their boiler wasn't producing as much steam as expected.
R&R and Tetra Engineering Group Inc. were asked to solve the issue with reduced steam production.
An inspection had shown that a significant amount of hot flue gas was bypassing the boiler tubes, where the heat was supposed to be transferred.
R&R Consult conducted a CFD analysis, which revealed that 6.3% of the flue gas was bypassing the boiler tubes without transferring heat. The analysis also showed that the flue gas was instead being directed along the sides of the boiler and between the modules that were supposed to capture the heat. This was the cause of the reduced performance.
Based on our results, Tetra Engineering installed covering plates to reduce the bypass flow. This improved the boiler's performance and increased electricity production.
It is always satisfying when we can help solve complex challenges like this. Do your systems also need a check-up or optimization? Give us a call!
Work done in cooperation with James Malloy and David Moelling from Tetra Engineering.
More examples of our work https://www.r-r-consult.dk/en/cases-en/
NO1 Uk best vashikaran specialist in delhi vashikaran baba near me online vas...Amil Baba Dawood bangali
Contact with Dawood Bhai Just call on +92322-6382012 and we'll help you. We'll solve all your problems within 12 to 24 hours and with 101% guarantee and with astrology systematic. If you want to take any personal or professional advice then also you can call us on +92322-6382012 , ONLINE LOVE PROBLEM & Other all types of Daily Life Problem's.Then CALL or WHATSAPP us on +92322-6382012 and Get all these problems solutions here by Amil Baba DAWOOD BANGALI
#vashikaranspecialist #astrologer #palmistry #amliyaat #taweez #manpasandshadi #horoscope #spiritual #lovelife #lovespell #marriagespell#aamilbabainpakistan #amilbabainkarachi #powerfullblackmagicspell #kalajadumantarspecialist #realamilbaba #AmilbabainPakistan #astrologerincanada #astrologerindubai #lovespellsmaster #kalajaduspecialist #lovespellsthatwork #aamilbabainlahore#blackmagicformarriage #aamilbaba #kalajadu #kalailam #taweez #wazifaexpert #jadumantar #vashikaranspecialist #astrologer #palmistry #amliyaat #taweez #manpasandshadi #horoscope #spiritual #lovelife #lovespell #marriagespell#aamilbabainpakistan #amilbabainkarachi #powerfullblackmagicspell #kalajadumantarspecialist #realamilbaba #AmilbabainPakistan #astrologerincanada #astrologerindubai #lovespellsmaster #kalajaduspecialist #lovespellsthatwork #aamilbabainlahore #blackmagicforlove #blackmagicformarriage #aamilbaba #kalajadu #kalailam #taweez #wazifaexpert #jadumantar #vashikaranspecialist #astrologer #palmistry #amliyaat #taweez #manpasandshadi #horoscope #spiritual #lovelife #lovespell #marriagespell#aamilbabainpakistan #amilbabainkarachi #powerfullblackmagicspell #kalajadumantarspecialist #realamilbaba #AmilbabainPakistan #astrologerincanada #astrologerindubai #lovespellsmaster #kalajaduspecialist #lovespellsthatwork #aamilbabainlahore #Amilbabainuk #amilbabainspain #amilbabaindubai #Amilbabainnorway #amilbabainkrachi #amilbabainlahore #amilbabaingujranwalan #amilbabainislamabad
Welcome to WIPAC Monthly the magazine brought to you by the LinkedIn Group Water Industry Process Automation & Control.
In this month's edition, along with this month's industry news to celebrate the 13 years since the group was created we have articles including
A case study of the used of Advanced Process Control at the Wastewater Treatment works at Lleida in Spain
A look back on an article on smart wastewater networks in order to see how the industry has measured up in the interim around the adoption of Digital Transformation in the Water Industry.
Water scarcity is the lack of fresh water resources to meet the standard water demand. There are two type of water scarcity. One is physical. The other is economic water scarcity.
Overview of the fundamental roles in Hydropower generation and the components involved in wider Electrical Engineering.
This paper presents the design and construction of hydroelectric dams from the hydrologist’s survey of the valley before construction, all aspects and involved disciplines, fluid dynamics, structural engineering, generation and mains frequency regulation to the very transmission of power through the network in the United Kingdom.
Author: Robbie Edward Sayers
Collaborators and co editors: Charlie Sims and Connor Healey.
(C) 2024 Robbie E. Sayers
1. Budapest University of Technology and Economics
Department of Measurement and Information Systems
Standards in Avionics System
Development
(Overview on DO-178B)
Ákos Horváth
Dept. of Measurement and Information Systems
2. Abstract
DO-178B (and DO-278) are used to assure safety
of avionics software. These documents provide
guidance in the areas of SW development,
configuration management, verification and the
interface to approval authorities (e.g., FAA, EASA)
2
3. Agenda
Introduction to DO-178B
System Aspects
Software Lifecycle Management
Certification Artifacts and Techniques
Future: DO-178C
3
4. Overview
DO-178B - Software Considerations in Airborne
Systems and Equipment Certification
Standard of RTCA Incorporation (in Europe it is ED-
12B and standard of EUROCAE)
Represents the avionics industry consensus to ensure
software safety
Acceptable by FAA and EASA certification authorities
„The FAA and the civil aviation community recognize
RTCA’S DO-178B as an acceptable means of
compliance to the FAA regulations for SW aspects of
certification.”
4
5. History of avionics SW complexity
5
0
50
100
150
200
250
300
350
400
MIPS LOC Mbyte/10 Digital links
A-310 (1983)
A-320 (1988)
A-340 (1993)
Exponential
Growth
Both A380 and B 787 have
100’s of millions LOC
Ref: Subra de
Salafa and
Paquier
6. History
DO-178 in 1982
o Basic concepts of SW design assurance
o Three levels of SW safety
DO-178A in 1985
o Concentrates on testing and configuration management
DO-178B in 1992
o Five levels of SW safety
o From Testing focus requirement-based
DO-278 in 2002
o Interprets DO-178B to ground and space based-systems
DO-178C in 2012
o Incorporates modern SW development and analysis
techniques
6
7. DO178B Document Structure
7
SW Life Cycle Process
System Aspects Relating To
Software Development (Sec 2.)
Overview of Aircraft and Engine
Certification (Sec. 10.)
Integral Process
SW Verification (Sec. 6.)
SW Configuration Mgt (Sec. 7.)
SW Quality Assurance (Sec. 8.)
Ceritfication Liasison (Sec. 9.)
SW Life Cycle (Sec. 3.)
SW Planning (Sec. 4.)
SW Development (Sec. 5.)
SW Life Cycle Data(Sec. 11.)
Additional Considration (Sec. 12.)
ANNEX A & B (FAA checklists) Appendices
8. Software Levels in DO-178B
Different failure conditions require different
software conditions 5 levels
8
9. Examples DO-178B Safety Levels
Safety-Critical Levels C&D
o Anti-missile defense
o Data mining
o Health monitoring
o Mission planning and
implementation
o Mission simulation and
training
o Network-centric operation
o Real-time data recording and
analysis
o Self-healing communication
networks
o Telemetry
o Weapons targeting
Safety-Critical Levels A&B
o Fly-by-wire controls
o Auto-pilot
o Air-traffic Separation Control
o Glass Cockpit Information
Display
o Radar
o Jet Engine Control
o IFF (friend or foe)
o Missile guidance
o Missile launch
o Missile self-destruct
9
10. Objectives for Safety Levels
10
Different levels of safety requires different objectives
to be fulfilled
o e.g., Level A 66, Level B 65
Defined by 10 tables in ANNEX A
Example: Table A-6 Objective 3.
Objective
Applicability
by SW Level
Output
Control
Category
by SW
Level
Description Ref A B C D Descriptions Ref. A B C D
Executable Object
Code compiles with
low-level
requirements
6.4.2.1.
6.4.3. ●●○
Software Verification
Cases and Procedures
Software Verification
Results
11.13
11.14
1
2
1
2
2
2
11. Objectives for Safety Levels
11
Different levels of safety requires different objectives
to be fulfilled
o e.g., Level A 66, Level B 65
Defined by 10 tables in ANNEX A
Example: Table A-6 Objective 3.
Objective
Applicability
by SW Level
Output
Control
Category
by SW
Level
Description Ref A B C D Descriptions Ref. A B C D
Executable Object
Code compiles with
low-level
requirements
6.4.2.1.
6.4.3. ●●○
Software Verification
Cases and Procedures
Software Verification
Results
11.13
11.14
1
2
1
2
2
2
Independence is
required (full means yes)
How to store the
evidence
12. Objectives Distribution in DO-178B
12
0
5
10
15
20
25
30
35
40
45
Planning Dev. Verif. CM QA Cert.
Level A (66)
Level B (65)
Level C (57)
Level D (28)
13. Objectives Distribution in DO-178B
13
0
5
10
15
20
25
30
35
40
45
Planning Dev. Verif. CM QA Cert.
Level A (66)
Level B (65)
Level C (57)
Level D (28)
Statement Coverage is
required (the only obj.
difference)
Not just testing
assuring the correctness
(reviews, testing and
analysis)
14. Agenda
Introduction to DO-178B
System Aspects
Software Lifecycle Management
Certification Artifacts and Techniques
Future: DO-178C
14
17. System Aspects and System Safety
System requirements „have to be trusted” start all
over if changed
Failure Condition Categories (Catastrophic, major,
etc.)
System Safety Assessment based on SAE ARP 4761
o Fault Tree Analysis, Dependence Diagram, Markov Analysis,
Failure mode and Effect analysis, Common Cause and
mode Analysis, etc.
SW requirements derived from System requirements
however, certain SW requirements can have
impact on System requirements!
17
18. SW Safety
SW Safety level based on potential failure conditions
o Level A „failure in the SW would result in catastrophic
failure condition the aircraft”
DO-178B defines the interface with the systems
DO-178B software classes
o User-modifiable software
• Entertainment software
o Option-selectable software
• Cartography software
o Commercial Off-The-Shelf software
• RTOS
o Field-Loadable software
• Maintenance software
18
19. Agenda
Introduction to DO-178B
System Aspects
Software Lifecycle Management
o Planning
o Development
Certification Artifacts and Techniques
Future: DO-178C
19
20. Software Life Cycle
Planning should proceed all development activity
Four building blocks :
o Define Requirements (R)
o Design the program (D)
o Code the program (C)
o Integrate the program (I)
Allows various development sequences
20
Example processes:
R-D-C-I Waterfall
R-C-I-C-I-C-I-R-D-C-I Rapid
prototyping
R-I Previous designed SW
21. The plans
Five different plans
o SW Development Plan
o SW Verification Plan
o SW Quality Assurance Plan
o SW Configuration Plan
o SW Aspects of Certification
Verification, management, quality assurance and
certification are overlaid on the defined
development process
21
22. Software Planning
Transition criteria
o „the minimum conditions, as defined by the software
planning process, to be satisfied to enter a process”
o Tells when you are done and can proceed
o Good characteristics: quantifiable, documented
Additional considerations
o COTS
o Previously developed components
Environments
o Methods and notations
o Language with any constraints
o Development and verification tools
22
23. Software Planning
SW development standards
o SW requirements standard
• Language to be used (e.g., plain 500 English)
o SW design standards
• Complexity limits, exclusion of recursion, dynamic memory
allocation
o SW Code standards
• Syntax, semantics and constraints
23
24. SW Development
24
High-Level requirements
o Based on system analysis
and safety assessment
o Black-box view of the
software component
o System level considerations
o Functional requirements by
mode of operation
o Performance criteria
o Timing requirements
o Memory size constraints
o HW and SW interfaces
25. SW Development
25
Low-Level requirements
and Software Architecture
o SW requirements
o Derived from High-Level
requirements
o Design constraints
• Task allocation
• Algorithms
• Data Structures
o Input/output definitions
o Data and Control flows
o Resource management and
scheduling (e.g., partition
scheduling in ARINC 653)
o Design Methods
26. SW Development
26
Source Code
o Usually collection of „high-
level” language and
assembly
o Includes linker files, compile
commands etc.
Executable
o Completely target computer
specific
o „machine readable”
Final output is the
integrated system on the
target platform
27. Agenda
Introduction to DO-178B
System Aspects
Software Lifecycle Management
Certification Artifacts and Techniques
o Verification
o Configuration Management
o Quality Assurance
o Certification/Approval Liaison
Future: DO-178C
27
28. Integral Process - Verification
Two purposes
o Demonstrate intended function
o Demonstrate (to the extent possible) the absence of
unintended function
Consists of
o Reviews
o Analysis
o Testing
Important: The FAA or EASA representative needs to
accept all part of the verification process. (e.g., test
cases)
28
29. Integral Process - Verification
Reviews
o Qualitative assessment of the process or product
o Typical implementation: checklist
o Applied on all SW Development process step (HLR,
LLR, SA, SC, Test cases, etc.)
Analysis
o Provide repeatable evidence of correctness
o Typical implementation: timing, stack analysis, data
flow and call-tree
29
30. Traceability DO-178B
Through the complete product
life-cycle (30+ years)
From requirements to byte code
(Level A)
Essential for maintainability
Back-annotation of errors
Typical implementation:
o Excel
o Rational RequisitePro
o Rational Doors
Code generators usually gives
extensive support
Hard in case of multiple
development tools
REQ_HLR_SAFE_4_3_2_12:
The take-off angle cannot be
more than 55°
REQ_LLR_TOM_3_67: in the eps_line
method the calculated s1 variable
represents the angle of attack
Traceability
32. Integral Process – Verification Software Testing
Categories of Tests
o Normal range
o Robustness (abnormal range)
Typical approaches
o Equivalence Classes and Boundary Values
o Multiple Iteration testing for time related functions
o Testing State Transitions
o Initialization with abnormal conditions
o Failure modes of input data
o Boundary values in loops, protection mechanisms
33
33. Integral Process – Verification Software Testing
Structural Coverage
o Determine what software structure were not exercised
Levels:
o Decision Coverage
o Statement Coverage
o Modified Decision Condition Coverage (MCDC)
• Each decision tries every possible outcome
• Each condition in a decision takes on every possible outcome
• Each entry and exit point is invoked
• Each condition in a decision is shown to independently affect the outcome of the decision
Gaps
o Complier induced code (e.g., array bound checks)
o Deactivated code
o Dead code
Performed on source code,
o except Level A
• Correspondence must be shown
• Complier optimization can introduce new code
In addition, coverage of data and control coupling is required
34
34. Integral Process – Verification Software Testing
# A B C
Foo
Executed
1 0 0 0 NO
2 0 0 1 NO
3 0 1 0 NO
4 0 1 1 YES
5 1 0 0 NO
6 1 0 1 YES
7 1 1 0 NO
8 1 1 1 YES
Coverage
Type
Minimum # of
Test Cases Possible Combinations
Statement 1 4 or 6 or 8
IF(C AND( A OR B))
THEN Foo(); Statement Coverage (SC)
Level C
o Each statement is executed
at least once
statement
35. Integral Process – Verification Software Testing
# A B C
Foo
Executed
1 0 0 0 NO
2 0 0 1 NO
3 0 1 0 NO
4 0 1 1 YES
5 1 0 0 NO
6 1 0 1 YES
7 1 1 0 NO
8 1 1 1 YES
Coverage
Type
Minimum # of
Test Cases Possible Combinations
Statement 1 4 or 6 or 8
Decision 2 4 or 6 or 8 + Any NO
IF(C AND( A OR B))
THEN Foo(); Decision Condition
Coverage (DC) Level B
o Each decision tries every
possible outcome
o Each entry and exit point is
invoke
decision
36. Integral Process – Verification Software Testing
# A B C
Foo
Executed
1 0 0 0 NO
2 0 0 1 NO
3 0 1 0 NO
4 0 1 1 YES
5 1 0 0 NO
6 1 0 1 YES
7 1 1 0 NO
8 1 1 1 YES
Coverage
Type
Minimum # of
Test Cases Possible Combinations
Statement 1 4 or 6 or 8
Decision 2 4 or 6 or 8 + Any NO
MCDC 4
2,3,4, and 6 OR 2,4,5
and 6
IF(C AND( A OR B))
THEN Foo(); Modified Decision Condition
Coverage (MCDC) Level A
o Each decision tries every possible
outcome
o Each condition in a decision takes on
every possible outcome
o Each entry and exit point is invoked
o Each condition in a decision is shown to
independently affect the outcome of the
decision
condition
37. Integral Process – Certification/Approval Liaison
Communication between application developer
and certification authority
Proposes compliance and obtain agreement on
the plan
Software Accomplishment Summary
o Covers all areas
o Legal issues also (if something goes wrong the
developer is responsible!)
42
38. Development Tool
SW Development Tools(DO-178B)
Software Development Tools
o Can introduce errors into the final system
o Same objectives as the development process verified on
the same level as the developed application!
o E.g., Scade Suite, Matlab Stateflow, Wind River Diab
compiler
39. Development Tool
V&V tools (DO-178B)
Software Verification Tools
o Can only fail to detect errors
o Tool operation req. Must be satisfied under normal
operating conditions
o e.g., static source code analyzer ASTRÉE, CAVEAT
40. Agenda
Introduction to DO-178B
System Aspects
Software Lifecycle Management
Certification Artifacts and Techniques
Future: DO-178C
46
41. DO-178C
DO-178C - Software Considerations in Airborne
Systems and Equipment Certification
Awaited in 2011
New certification for avionics software development
Incorporates ”novel” development and verification
techniques
Core is almost the same as DO-178B but
Dedicated subgroups
o SG3: Tool Qualification
o SG4: Model Based Design and Verification
o SG5: Object-Oriented Technology
o SG6: Formal Methods
47
42. DO-178C
Object Oriented Technology
o C++ and Ada
o Safety Critical Java
o Restricted use (deterministic behavior)
Tool Qualification
o Special rules for tools
o More than two categories
Model Based Design and Verification
o Use of models for source code synthesis and verification
o Early model based validation
o Matlab Simulink (already used), AADL
o Largest and most cumbersome subgroup
48
43. DO-178C
Formal methods
o Already used in many projects
o Mature technologies available
o Defines how certification credits can be earned by its
use
o Can be part of the Development process
o Typical tools
• Model checker
• Static code analyzers
• Theorem provers (only in limited scenarios)
49