Free 30-day trial DO-178C Handbook RapiCoupling Preview DO-178C Multicore Training Multicore Resources

Back to Top Contact Us

404 - Page not found

404 - Page not found!

Content which may include .

Software Engineering Team Lead (algorithms, static analysis, R&D, aerospace)

What does AMACC Rev B mean for multicore certification?

Requirements traceability with RapiTest and Polarion ALM

IEEE SMC-IT/SCC 2025

Software Project Manager (6-Month Contract from September, York)

Rapita partners with Asterios Technologies to deliver solutions in multicore certification

Simulation of the Motorola 68020 microprocessor with Sim68020

Certifying Unmanned Aircraft Systems

How to make AI safe in autonomous systems with SAIF

How emulation can reduce avionics verification costs: Sim68020

Multicore timing analysis: to instrument or not to instrument

Avionics and Testing Innovations 2025

XPONENTIAL 2025

SAIF Autonomy to use RVS to verify their groundbreaking AI platform

Rapita Systems - Safety Through Quality

Simulation for the Motorola 68020 microprocessor with Sim68020

AI-driven Requirements Traceability for Faster Testing and Certification

Multicore software verification with RVS 3.22

RVS 3.22 Launched

Trailblazer Program

Which DO-178C objectives can RapiCover Zero help me to achieve?

Which DO-178C objectives can RapiTime Zero help me to achieve?

Which DO-178C objectives can RapiTime help me to achieve?

Which DO-178C objectives can RapiCover help me to achieve?

Which DO-178C objectives can RapiTest help me to achieve?

Which DO-178C objectives can RVS help me to achieve?

Which AC 20-193 and AMC 20-193 objectives can MACH178 Foundations help me to achieve?

Multicore test formats

Multicore testing

Hybrid electric pioneers, Ascendance, join Rapita Systems Trailblazer Partnership Program

How are unexpected behaviors discovered on multicore platforms?

Are unknown behaviors often discovered during platform analysis? If so, how do you validate them?

How many multicore certifications have been completed using Rapita’s approach to A(M)C 20-193 compliance?

What feedback have certification authorities given on the MACH178 approach? Is it proven?

What execution time margin should be used?

Can statistical models be used for multicore WCET analysis? Is it sufficient to be x standard deviations away from the mean?

How can you test software running on a continuous loop expecting external inputs?

How do you know you have tested all required permutations of interference channels?

What do I need to test for my software?

What qualification level should interference generators be classified at?

Can interference generators interfere with each other?

For which objectives are interference generators required?

Do you have a list of potential interference channel mitigations?

Don’t many mitigations put too much trust in the scheduling and partitioning mechanisms?

How does deactivating resources impact certification?

Is a parallel or sequential approach to analyzing resources most efficient?

How do I identify interference channels?

How much of a challenge is vendors not having or not sharing information about platform components?

How can I ensure that multicore platform components delivered at different time points exhibit the same behavior?

What is the impact on certification if applications move between cores?

Is IMA compatible with multicore processors?

Is it possible to use GPUs in multicore systems? What is the certification impact?

Is it possible to use simultaneous multithreading in multicore systems? What is the certification impact?

How can I ensure that a platform will have the required performance with multicore interference taken into account before verification?

Do you have any recommendations for structuring plans for A(M)C 20-193?

Is the USAF document AA-22-01 equivalent to A(M)C 20-193?

How much rigor is enough to demonstrate airworthiness for defense avionics? Where do you draw the line?

What role does thermal/environmental testing have in A(M)C 20-193?

How much effort does it take to verify multicore software to A(M)C 20-193?

Which activities are required if using a multicore processor with all cores but one deactivated?

Our certification authorities are never satisfied with the evidence provided. How much is enough?

Do the certification authorities agree on the definitions used in the A(M)C 20-193 guidance?

Is there a difference between what different certification authorities expect in terms of meeting A(M)C 20-193 objectives?

Which activities are required to certify multicore systems to DAL D?

As some A(M)C 20-193 objectives aren’t indicated for DAL C systems, do I not need to perform related activities for DAL C?

Which objectives do I need to meet? Are alternative paths to compliance available?

How to certify multicore processors - what is everyone asking?

Software verification for ANSYS SCADE projects with RVS

How can I learn more about certifying multicore software?

Why is it not possible to obtain MC/DC from object code in the general case?

Software verification for MATLAB Simulink projects with RVS

Magline joins Rapita Trailblazer Partnership Program to support DO-178 Certification

Eve Air Mobility joins Rapita Systems Trailblazer Partnership Program for eVTOL projects

Rapita Systems launches MACH178 Foundations for multicore DO-178C compliance

Streamlined AMC 20-193 compliance with MACH178 Foundations

Data Coupling Basics in DO-178C

GMV verify ISO26262 automotive software with RVS

MACH178 Foundations

Which AC 20-193 and AMC 20-193 objectives can MACH178 help me to achieve?

How can I get more support for my multicore project?

What can I expect to learn in the training?

How is MACH178 Foundations licensed?

How can I execute the MACH178 workflow with MACH178 Foundations?

How can I use MACH178 Foundations?

How is MACH178 Foundations delivered?

Collins Aerospace and Rapita present award winning paper at DASC 2024

Polarion® ALM™

Mitigation of interference in multicore processors for A(M)C 20-193

Kappa: Verifying Airborne Video Systems for Air-to-Air Refueling using RVS

DCCC Analysis with RapiCoupling (Preview)

.nav-link { background-color: #2.nav-pills .nav-link.active, .nav-pills .show>.nav-link { background-color: #2c3584 !important; } c3584 !important; } .wpform, .popup_container, .popup_container2, .popup_container3 { padding: 20px; background-color: white; } /* Flexible iFrame */ .flexible-container { position: relative; padding-bottom: 56.25%; padding-top: 30px; height: 0; overflow: hidden; } .wpform .formheader { padding-left: 0px; } .single-webinar .card .card-img-top { padding: 0px; } .single-webinar .card-body a { color: black !important; } .single-webinar .card-body { min-height: 215px; } @media only screen and (max-width: 992px) and (min-width: 768px) { .card-row .col-md-7 { margin: auto; } } @media only screen and (max-width: 1200px) and (min-width: 992px) { .single-webinar .card-body { min-height: 240px; } } .discoform #edit-download-choice--3--wrapper span { font-size: 20px; } .flexible-container iframe, .flexible-container object, .flexible-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; } .list-group { margin-bottom: 10px; } #dal-table thead th { background: none; } .overlay-image { overflow: hidden; height: 100%; z-index: 2; } .infoitem { margin-top: -10px; } .videoWrapper { margin-top: 60px; } .closepopup1 a, .closepopup2 a, .closebutton a { font-size: 25px; color: black !important; padding-right: 20px; cursor: pointer; } .closebutton { text-align: right; margin-top: -15px; margin-right: -15px; } .jumbotron .display-4 { font-size: 2.5em; padding-top: 25px; } .jumbotron .wp_dw { width: 100%; text-align: center; } #formbox2.active, #formbox.active, #formbox3.active, #formbox4.active { display: flex; justify-content: center; align-items: center; } #formbox, #formbox2, #formbox3.active, #formbox4.active { position: fixed; z-index: 1000; top: 0; width: 100%; height: 100%; background-color: rgba(0, 0, 0, .8); display: none; } .top-bnr { background-image: url("/files/iStock-1754365736%20%281%29.png"); background-repeat: no-repeat; background-size: cover; background-position: center; } .mesh { background-image: url(../files/mesh_bg.png); background-repeat: no-repeat; } .top-heading h1 { color: white; font-size: 50px; } .doimg { width: 100%; height: auto; } .form-holder { padding: 90px 10px 10px 10px; } .node--type-discovery-page .form-holder .discoform legend span { color: white; } .node--type-discovery-page form-holder .privacy-notice { color: white !important; } .form-holder .discoform .privacy-notice, .discoform .privacy-notice a { color: white !important; } .top-paragraph p { color: white; font-size: 18px; } .top-img { margin-top: -100px; } .white-bnr, .slide-bnr { padding: 50px 0; background-image: url(../files/white_bg.png); background-repeat: no-repeat; background-size: cover; background-position: right; } .grey-bnr { padding: 50px 0; background-image: url(../files/mesh_bg.png); background-repeat: no-repeat; background-size: contain; } .graybg { background-color: #f9f9f9; padding: 50px 0; } .dark-bnr { padding: 50px 0; background: linear-gradient(-8deg, #2c3584, #0e3754 45%, #376789 75%, #2c3584); background-repeat: no-repeat; } .slide-bnr { padding: 10px 0 50px 0; } .dal-cards .card { margin: 10px 0; } .dal-cards .card .card-link { float: right; } .dal-cards .card .card-text { font-size: 1em !important; } .freetrialbtn { background-color: orange; color: white; } .dal-cards .card:hover .card-body { background: linear-gradient(-138deg, #ffa500 0, #f37a20 55%, #ffa500 100%); transition: linear .2s; color: white !important; } .dal-text { color: white; } .dal-text h2 { color: white !important; } .dal-cards .card:hover .card-title { color: white !important; } .dal-cards .card:hover .card-link { color: white !important; } .card-img-top { padding: 0 50px; } #dal-table td { background: none !important; } .highlighted { position: relative; width: auto; height: auto; display: flex; justify-content: center; align-items: center; } .discoform input { color: black; } .highlighted img { width: 100%; height: 100%; } .highlighted:before { content: ""; display: block; position: absolute; top: 0; bottom: 0; left: 0; right: 0; width: auto; height: auto; background: rgba(255, 255, 255, 0.6); } .jumbotron video { padding-top: 60px; } .jumbotron { background-color: #2c3584 !important; background-image: url(/themes/contrib/rapita2020/css/base/bg_wedge.svg); background-size: cover; padding-top: 50px !important; padding-bottom: 50px !important; margin-bottom: 0 !important; } .jumbotron .display-4, .jumbotron .lead { color: white; } .list-group-item.active { background-color: #2c3584 !important; border-color: #2c3584 !important; } .sidebar { width: 50px; transition: linear 0.3s; position: fixed; right: 0; text-decoration: none; color: #fff; border-radius: 0 5px 5px 0; top: 250px; z-index: 99999; } .sidebar .sidebtn { width: 320px; height: 50px; position: relative; right: 135px; top: 135px; margin: 0; border-top-right-radius: 8px; border-top-left-radius: 8px; box-shadow: 0 10px 14px 10px rgb(238 58 36 / 26%); text-align: center; line-height: 40px; transform: rotate(-90deg); -webkit-transform: rotate(-90deg); color: white !important; font-size: 20px; } * { box-sizing: border-box } .mySlides, .wpSlides { display: none } .mySlides img, .wpSlides { vertical-align: middle; border: 1px solid lightgrey; } .fade:not(.show) { opacity: 1; } /* Slideshow container */ .slideshow-container { max-width: 1000px; position: relative; margin: auto; } /* Next & previous buttons */ .prev { margin-left: -40%; } .next { margin-right: 10%; } .prev, .next { cursor: pointer; position: absolute; width: auto; padding: 16px; margin-top: -22px; color: white; font-weight: bold; font-size: 18px; transition: 0.6s ease; border-radius: 0 3px 3px 0; user-select: none; } /* Position the "next button" to the right */ .next { right: 0; border-radius: 0px 5px 5px 0px; } .prev { border-radius: 5px 0px 0px 5px; } /* On hover, add a black background color with a little bit see-through */ .prev:hover, .next:hover { background-color: rgba(0, 0, 0, 0.8); color: white !important; } .slideshow-container:not(.sbutton), .mySlides { text-align: left; } /* Caption text */ .text { color: black; padding: 8px 12px; bottom: 8px; width: 100%; text-align: center; font-size: 0.8em; } /* The dots/bullets/indicators */ .dot, .wpdot { cursor: pointer; height: 15px; width: 15px; margin: 0 2px; background-color: #bbb; border-radius: 50%; display: inline-block; transition: background-color 0.6s ease; } /* Fading animation in slideshow*/ .fade { -webkit-animation-name: fade; -webkit-animation-duration: 1.5s; animation-name: fade; animation-duration: 1.5s; } @-webkit-keyframes fade { from { opacity: .4 } to { opacity: 1 } } @keyframes fade { from { opacity: .4 } to { opacity: 1 } } DO-278A RTCA DO-278A / EUROCAE ED-109A is the main document used for the development of ground-based software systems that support aircraft operations. The document, titled “Guidelines for Communication, Navigation, Surveillance, and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance” is the primary document by which authorities such as the FAA and EASA approve software used in ground-based systems involved in aircraft operations. Download DO-178C Handbook Verification webinar series Introduction Assurance Levels DO-278A processes Tool qualification How we help Introduction to DO-278 & DO-278A Design assurance guidance for aircraft software began with the release of DO-178 (ED-12) and later versions, DO-178A (ED-12A) and DO-178B (ED-12A). These documents provided the means by which software developed for use in civil aircraft operations were certified for use by the FAA and EASA. DO-278 was originally developed as a supplement to DO-178B to cover additional factors relative throughout the design assurance process. That is, the two documents were used together for approval of ground-based software involved in aircraft operations. DO-278A was released in December 2011. This document unified the guidance in DO-178C and DO-278 to yield a single document for design assurance of ground-based software involved in aircraft operations. Collins Aerospace How RapiCover was used for DAL A code coverage analysis for a complex flight control system. View case study Triumph Group How Rapita's V&V services produced evidence for certification of actuation system software. View case study Cobham Aerospace Rapita tools efficiently produced coverage evidence for DO-178C DAL C certification of an antenna control unit. View case study OHB Sweden How RapiCover improved code coveage analysis for DO-178C attitude orbital control system. View case study Assurance Levels DO-278 introduced (and DO-278A continued to use) the fundamental concept of the Assurance Level (AL), which defines the amount of rigor that should be applied by the integrity assurance process based on the contribution to CNS/ATM system failure conditions. The lower the AL, the more activities and objectives that must be performed and met as part of the integrity assurance process because of the more severe consequences should the software fail or malfunction. The six ALs, which are summarized in the table below, determine the amount of rigor required in the development and testing of a specific piece of software. AL Condition 1 Catastrophic 2 Hazardous 3 Major 4 Minor 5 - 6 No safety effects DO-278A processes Planning Development Integral Planning DO-278A planning is the first DO-278A process that should occur and follows the basic design assurance principle that you say what you are going to do before you do it so you can ensure that what you plan to do will meet the required DO-278A objectives and provide evidence to demonstrate this. Development of a set of plans covering all components of the Design Assurance process is a cornerstone of DO-278A. As part of this activity, the following plans must be developed: Plan for Software Aspects of Approval (PSAA): a description of the software you plan to develop, the hardware environment it will be used in, the design assurance processes you will follow, and how you will demonstrate compliance, including how you will verify your implemented code and any commercial tools you will use in your verification. Software Development Plan (SDP): a description of the software development processes and the software life cycle that is used to satisfy DO-278A objectives. Software Verification Plan (SVP): a description of the verification processes (Reviews, Analyses and Tests) used to satisfy DO-278A objectives. Software Configuration Management Plan (SCMP): a description of the methods and environment that will be used to configure all of the design data and compliance evidence needed to achieve DO-278A approval. Software Quality Assurance Plan (SQAP): a description of the methods and associated records that will be used to ensure that DO-278A quality assurance objectives are satisfied. Development Development covers all of the activities that involve design and production of DO-278A software that meets system requirements of the project. This includes definition of high and low-level software requirements, software architecture definition and implementation of the software. Requirements should be developed in order to meet system requirements of the component hosting the software. These system requirements may be decomposed into hardware requirements (DO-254) as well as software components. Requirements should be verifiable as they will need to be verified in order to generate compliance evidence. The software architecture must be designed before the software is implemented. It is worth considering how the software architecture will affect verification efficiency as verification comprises a large proportion of the cost of a DO-278A project. Particularly, it is worth considering how your architecture will affect the efficiency of data coupling and control coupling analysis of your implemented software. Engineers new to DO-278A may be surprised at how small a proportion of overall effort Implementation takes in a DO-278A project, particularly at high ALs e.g. AL 1. As verification is much morwe effort intensive than implementation, it is worth considering how implementation decisions such as choice of language and language constructs used, choice of hardware platform and choice of compiler and compiler options will affect verification efficiency. Integral processes DO-278A includes 4 Integral processes, which are followed throughout a DO-278A project. These are Verification, Configuration Management, Quality Assurance and Approval Liaison. Integral processes should be planned during DO-278A planning. Following the processes should generate evidence that can be provided to certification authorities to demonstrate that you have followed the processes you planned to (and agreed with the certification authority). Verification covers activities needed to demonstrate that DO-278A software functions as intended. You will plan a Verification strategy in your Software Verification Plan and follow this after. Some Verification activities should be achieved by testing, while some are achieved by reviews. Software tools are often used to reduce the effort needed to verify DO-278A software. Configuration Management covers the processes by which you will control and track versioning of items developed during DO-278A projects, including software and documents such as reviews. Your Configuration Management process must generate a record of every version of every item, and these should be accessible throughout the project. Quality Assurance covers activities that demonstrate that you are following the plans and standards that you have said you will follow throughout a DO-278A project. This includes change control, problem reporting and conducting a conformance review to ensure that your DO-278A software and related documents are ready to share with your certification authority in the final Stage of Involvement (SOI). Approval Liaison covers activities in which you will interact directly with your certification authority, including the processes you will follow to prepare for and conduct the DO-278A SOIs with them. Free 70-page handbook download Efficient verification through the DO-178C life cycle DO-278A is almost identical to DO-178C, making this handbook a great starting point for understanding the DO-278A process and how to efficiently verify DO-278A software. Download now Tool qualification As per DO-278A, you need to qualify any software tool you use that replaces or mitigates any DO-278A process and for which the output is not manually verified. The qualification process ensures that such software tools can be relied upon to produce appropriate and repeatable results. DO-278A itself describes when a tool must be qualified, but does not go into detail on how this should be done. The DO-330: Software Tool Qualification Considerations supplement to DO-278A expands on this guidance by defining corresponding objectives for the specification, development and verification of qualified tools. If you use any commercial verification tools to automate DO-278A verification processes and don’t plan on manually reviewing output from the tools, they will need to be qualified at the appropriate tool qualification level. Many commercial verification tools have supporting qualification kits, which include evidence needed to demonstrate that the activities the tool developer must perform have been performed. All qualification kits should include all of the evidence needed from the tool developer. Some qualification kits may also include supporting material to help meet tool user objectives. How can Rapita help? Verification tools V&V Services Systems engineering Tool support Training The Rapita Verification Suite (RVS) reduces the effort needed to verify DO-278A software by helping to satisfy specific DO-278A objectives. RVS includes plugins that satisfy requirements-based functional testing, structural coverage analysis and worst-case execution time analysis and is supported by a qualification kit and service to provide DO-330 tool qualification evidence. To see how RVS could help you, contact us or download a free trial today. Our Verification and Validation Services help satisfy DO-178C objectives. We provide services covering the full DO-278A life cycle, supporting efficient Planning, Development, and Integral processes including software verification using RVS. Our engineering team have diverse experience working in civil and defense avionics development and verification worldwide. To see how our V&V Services could help you, download our brochure or contact us. Our systems engineering services, with our emphasis on quality and adherence to ARP4754A industry guidance, support the development of systems with well-designed hardware and software. We support system integration and verification and validation of system requirements. Our automated V&V tools integrate with industry standard requirements management software to capture results while seamlessly maintaining traceability to requirements. Find out more about our systems engineering services. Our support team is comprised of our Field Application Engineers (FAEs), who use RVS every day and regularly perform integrations involving a variety of compilers, languages, and platforms. Our policy is to always provide our customers with the best level of support we can realistically achieve, and as such we resolve support issues as quickly and effectively as we can. We have a strong history of excellent support and regard this as an essential aspect of our business. For more information on our support service, see our Support web page. We provide training in a range of expert topics, including: DO-178C compliance, Multicore certification and setting up automated test environments. Our training is flexible; we offer both face-to-face and virtual training and offer custom training courses to meet your specific needs. For more information on our training solutions, see our Training web page. Verification webinar series Functional testing Learn from V&V experts how to manage your functional testing workflow from writing requirements through to producing test evidence from qualified automation tools. Code coverage Explore a range of code coverage topics (MC/DC, object code coverage) and best practices that you can put into practice in your project to obtain 100% coverage. WCET analysis Learn about the different WCET analysis approaches and how to select the best WCET analysis tool to meet the needs of DO-178C. DO-178C handbook preview Read the first chapter The safety assessment processes used in all functional safety domains rely on demonstrating that the probability of system failure that could cause harm is below an acceptable threshold. When a system is made up of mechanical and electronic components, for which the component failure rate is known, the probability of failure for the system can be calculated and achievement of the safety target can be demonstrated. For software, complex systems or electronic hardware, system failures can be caused by design errors (sometimes known as systematic failures) as well as component failures, but there is no agreed way of calculating the failure rate of these design errors. In the aerospace domain, the agreed approach for dealing with design errors is to implement design assurance processes that have specific activities to identify and eliminate design errors throughout the software development life cycle. DO-178 was originally developed in the late 1970s to define a prescriptive set of design assurance processes for airborne software that focused on documentation and testing. Design Assurance Levels (DALs) DO-178B introduced (and DO-178C continued to use) the fundamental concept of the Design Assurance Level (DAL), which defines the amount of rigor that should be applied by the design assurance process based on the contribution to Aircraft Safety. The higher the DAL, the more activities and objectives that must be performed and met as part of the Design Assurance process because of the more severe consequences to the aircraft should the software fail or malfunction. Design Assurance Level A (DAL-A) is the highest level of design assurance that can be applied to airborne software and is applied when failure or malfunction of the software could contribute to a catastrophic failure of the aircraft. The activities and objectives that must be met through the Design Assurance process gradually decrease with each level alphabetically until DAL-E, which has no objectives as there is no consequence to aircraft safety should such software fail or malfunction. Objectives and activities The recommendations given in DO-178 fall into two types: Objectives, which are process requirements that should be met in order to demonstrate compliance to regulations Activities, which are tasks that provide the means of meeting objectives In total, DO-178C includes 71 objectives, 43 of which are related to verification. The number of these objectives that must be met for compliance reduces as the Design Assurance Level of the system reduces. Supplementary objectives and guidance DO-178C introduced three technology supplements to provide an interpretation of the DO-178C activities and objectives in the context of using specific technologies. The three technologies are Model Based Development and Verification (DO-331), Object Oriented Technology and related technologies (DO-332), and Formal Methods (DO-333). Each supplement describes the technology, defines the scope of its use within airborne software, lists additional or alternative activities and objectives that must be met when the technology is used, and includes specific FAQs (Frequently Asked Questions) that clarify objectives and activities relating to the technology. A further supplement was introduced in DO-178C, Software Tool Qualification Considerations (DO-330), which gives guidance on the qualification of tools used in software development and verification processes. This guidance can be applied to any tools, not just those used for software development or verification, for example systems design or hardware development tools, and acts more like a stand-alone guidance document than the other supplements mentioned. Many other documents support DO-178C by providing additional clarification or explanations that can help developers to correctly interpret the guidance and implement appropriate design assurance processes. The Supporting Information (DO-248C) supplementary document includes FAQs relating to DO-178C, and the document is commonly referred to by the title Frequently Asked Questions. In addition to the FAQs in DO-248C, the document provides the rationale for the activities and objectives listed in DO-178C and includes discussion papers that provide clarification on specific topics related to software development and verification. A series of documents produced by the Certification Authorities Software Team (CAST) since the release of DO-178B provided information on specific topics of concern to certification authorities in order to harmonize approaches to compliance. These topics have had a greater scope than just Software concerns, and much of the content in CAST documents has been implemented in guidance updates such as DO-178C, or formed the basis of authority publications, such as A(M)C 20-193 to address the use of multicore processors in avionics and A(M)C 20-152A on the development of airborne electronics hardware. CAST has remained inactive since October 2016 and links to most previous CAST papers have been removed from the FAA’s website........... Continue reading Learn more about DO-278A related subjects AC 20-193 AMC 20-193 Verifying multicore systems. EUROCAE ED-215 RTCA DO-330 Software Tool Qualification Considerations. EUROCAE ED-216 RTCA DO-331 Model-based development and verification supplement. EUROCAE ED-217 RTCA DO-332 Object-oriented technology and related techniques supplement. EUROCAE ED-12C RTCA DO-178C Software Considerations in Airborne Systems and Equipment Certification. DO-178C Handbook Preview ❮ ❯ Efficient verification through the DO-178C life cycle Following DO-178C guidance when developing safety-critical avionics software can be complex, and there are many potential pitfalls along the way. This handbook takes you through the whole DO-178C journey with a focus on verification, leaving you with an understanding of the compliance process as a whole and practical tips to efficiently verify DO-178C software. Download in full window.onload = function() { jQuery(document).ready(function() { jQuery('.footer').addClass('sidetriggeroff'); //pop-up formbox implementation const formbox = document.createElement('div'); formbox.id = 'formbox'; document.body.appendChild(formbox); const formbox2 = document.createElement('div'); formbox2.id = 'formbox2'; document.body.appendChild(formbox2); function showform() { formbox2.classList.remove('active'); formbox.classList.add('active'); jQuery('.popup_container').removeClass('hide'); jQuery('.popup_container').appendTo('#formbox'); } function showform2() { formbox.classList.remove('active'); formbox2.classList.add('active'); jQuery('.wpform').removeClass('hide'); jQuery('.wpform .closebutton').removeClass('hide'); jQuery('.wpform').appendTo('#formbox2'); } jQuery('.sidebtn').on('click', function(e) { e.preventDefault(); jQuery('.wpform').addClass('hide'); formbox2.classList.remove('active'); showform(); }); jQuery('.wp_dw').on('click', function(f) { f.preventDefault(); jQuery('.popup_container').addClass('hide'); formbox.classList.remove('active'); showform2(); }); jQuery('body').delegate('.closepopup1 a', 'click', function(f) { f.preventDefault(); jQuery('#formbox').removeClass('active'); }); jQuery('body').delegate('.closebutton a', 'click', function(f) { f.preventDefault(); jQuery('#formbox2').removeClass('active'); }); }); //handle "How Rapita can help list" jQuery('body').on('click', '.closepopup1 a', function(f) { f.preventDefault(); jQuery('#formbox').removeClass('active'); }); jQuery('body').on('click', '.closeform a', function(f) { f.preventDefault(); jQuery('#formbox2').removeClass('active'); }); jQuery('body').on('click', '.list-group-item', function(e) { jQuery('.list-group-item').each(function() { jQuery(this).removeClass('active'); }); jQuery(this).addClass('active'); }); jQuery('body').on('click', '#l1', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l1').removeClass('hide'); }); jQuery('body').on('click', '#l2', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l2').removeClass('hide'); }); jQuery('body').on('click', '#l3', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l3').removeClass('hide'); }); jQuery('body').on('click', '#l4', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l4').removeClass('hide'); }); jQuery('body').on('click', '#l5', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l5').removeClass('hide'); }); jQuery('body').on('click', '#l6', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l6').removeClass('hide'); }); //function for toggling sidebar button function isIntoView(elem) { var documentViewTop = jQuery(window).scrollTop(); var documentViewBottom = documentViewTop + jQuery(window).height(); var elementTop = jQuery(elem).offset().top; var elementBottom = elementTop + jQuery(elem).height(); return ((elementBottom = documentViewBottom) & amp; & amp; (elementTop = documentViewTop)); } jQuery(window).scroll(function() { if (isIntoView(jQuery('.sidetrigger'))) { jQuery('.sidebar').removeClass('hide'); } }); //turn of sidebar button when on top of page jQuery(window).scroll(function() { if (isIntoView(jQuery('.sidetriggeroff'))) { jQuery('.sidebar').addClass('hide'); } }); //slideshow function var slideIndex = 1; s = document.getElementsByClassName("mySlides"); d = document.getElementsByClassName("dot"); showSlides(slideIndex, s, d); highlightslide(); function plusSlides(n) { s = document.getElementsByClassName("mySlides"); d = document.getElementsByClassName("dot"); showSlides(slideIndex += n, s, d); highlightslide(); } function currentSlide(n) { s = document.getElementsByClassName("mySlides"); d = document.getElementsByClassName("dot"); showSlides(slideIndex = n, s, d); highlightslide(); } // for wp preview var slideIndex = 1; s = document.getElementsByClassName("wpSlides"); d = document.getElementsByClassName("wpdot"); showSlides(slideIndex, s, d); function pluswpSlides(n) { s = document.getElementsByClassName("wpSlides"); d = document.getElementsByClassName("wpdot"); showSlides(slideIndex += n, s, d); } function currentwpSlide(n) { s = document.getElementsByClassName("wpSlides"); d = document.getElementsByClassName("wpdot"); showSlides(slideIndex = n, s, d); } function showSlides(n, s, d) { var i; var slides = s var dots = d if (n & amp; gt; slides.length) { slideIndex = 1 } if (n & amp; lt; 1) { slideIndex = slides.length } for (i = 0; i & amp; lt; slides.length; i++) { slides[i].style.display = "none"; slides[i].classList.remove("active-slide"); } for (i = 0; i & amp; lt; dots.length; i++) { dots[i].className = dots[i].className.replace(" active", ""); } slides[slideIndex - 1].style.display = "block"; slides[slideIndex - 1].classList.add("active-slide"); dots[slideIndex - 1].className += " active"; } function highlightslide() { jQuery(".overlay-image").removeClass("highlighted"); var stage = "#" + jQuery(".active-slide").attr("data-process") + " .overlay-image"; jQuery(stage).addClass("highlighted"); } } "> DO-278A Guidance: Introduction to RTCA DO-278 approval

RVS 3.21 Launched

Streamlined software verification with RVS 3.21

Embedded Office GmbH & Co. KG and Rapita Systems announce strategic partnership

Supporting DanLaw with unit testing and code coverage analysis for automotive software

Multicore Webinar with Asterios Technologies

RVS Tool Qualification for DO-278A

RVS Tool Qualification for DO-178C

RVS Tool Qualification for DO-178C Order Information

Integrating & verifying time-critical applications on multicore platforms

Control Coupling Basics in DO-178C

Trailblazer Program (EVTOL)

MACH178 Foundations Order Information

Is instrumentation-based or instrumentation-free analysis best for me?

Is instrumentation-based or instrumentation-free analysis best for me?

Is instrumentation-based or instrumentation-free analysis best for me?

Is instrumentation-based or instrumentation-free analysis best for me?

Can I use RapiTask if I don’t have access to my project source code?

Can I use RapiTime if I don’t have access to my project source code?

Can I use RapiCover if I don’t have access to my project source code?

Can I use RVS if I don't have access to my project source code?

Rapita Systems and LICRIT announce strategic partnership

EdgeAI-Trust: Decentralized Edge Intelligence: Advancing Trust, Safety, and Sustainability in Europe

MACH178 Services overview

SCHEME: Safety-Critical Harsh Environment Micro-processing Evolution

DO-178C Multicore In-person Training (Fort Worth, TX)

DO-178C Multicore In-person Training (Munich)

Head of Engineering Services - Aerospace Software, York UK (hybrid)

MACH178 Tools overview

MACH178 Foundations overview

MACH178 overview

Which services support MACH178?

Which software tools support MACH178?

What is MACH178 Foundations?

Lay the groundwork for A(M)C 20-193 compliance with MACH178 Foundations

Supporting your A(M)C 20-193 compliance with MACH178 Services

DO-278A qualification kit

DO-278A qualification kit

Components in Data Coupling and Control Coupling

Rapita Verification Suite (RVS) Training Brochure

A(M)C 20-193 vs AA-22-01 Webinar

Process improvement

V&V process optimization

Using a single core of a multicore processor

A(M)C 20-193 vs AA-22-01

The ‘A’ Team comes to the rescue of code coverage analysis

Custom consultancy

Data Coupling and Control Coupling process definition

Multicore platform evaluation

Multicore certification support

Why there’s no standard approach for Data Coupling and Control Coupling Analysis

Unlocking DO-178C Compliance Webinar

Unlocking DO-178C Compliance Webinar

DO-178C Multicore In-person Training (Bristol)

DO-178C Multicore In-person Training (Anaheim, CA)

Launching critical software to success with RVS 3.20

RVS Space Order Information

Kickstart your verification with RVS tutorials

DO-178C Multicore In-person Training (Madrid)

RVS 3.20 Launched

Which certification standards and guidelines can RVS help me to achieve?

How is RapiCover Zero optimized to support my industry?

How is RapiCover optimized to support my industry?

How is RVS optimized to support my industry?

Mitigation of interference in multicore processors webinar

Mitigation of Interference in Multicore Processors

Aerospace Tech Week Europe 2024

Introduction to Data Coupling and Control Coupling for DO-178C

Upcoming Webinar: Deep Dive on Multicore Interference

Deep Dive on Multicore Interference

DO-178C Multicore Certification Workshop at Aerospace Tech Week

Data Coupling & Control Coupling

Verifying additional code for DO-178C

NXP's MCFA 2023

DO-178C Multicore In-person Training (Toulouse)

RVS 3.19 Launched

Viewing software behavior at a glance with RVS treemaps

Using support functions with RapiTest

Streamlined software verification with RVS 3.19

Rapita is proud to be an ISOLDE Partner

ISOLDE : Demonstrating High Performance RISC-V Processing Systems and Platforms

Rapita and SYSGO underline partnership

Developing DO-178C and ED-12C-certifiable multicore software

DO-178C Multicore In-person Training (Huntsville)

How does RapiTime Zero support results collection from multiple test runs?

How can RapiTest let me test my unmodified object code?

How does RapiTest help me write complex or reusable test logic in my tests?

How does RVS supplement my Simulink model-based development workflow?

Support functions

Collect coverage incrementally

Test what you compile

Automatically merge timing results

MATLAB® Simulink®

Automotive electronics

Software engineering

Challenges of certifying multicore avionics in line with A(M)C 20-193 objectives - ATW Europe 2023

Data coupling and control coupling solutions for DO-178C

DO-178C multicore training

MOSA, FACE & SOSA TIM and Expo

Measuring response times and more with RapiTime

Streamlined software verification with RVS 3.18

RVS 3.18 Launched

Sequence analysis with RapiTime

Visualize call dependencies with RVS

Analyze code complexity with RVS

Solid Sands partners with Rapita Systems

Aeromart Montreal 2023

Multicore timing solutions for automotive

Reduce your automotive V&V effort with Rapita Systems

How can RVS help me understand my code base?

How does RapiTime support additional types of timing analysis such as response time analysis?

Response time analysis

Analyze timing behavior across code sequences

How does RVS support the analysis of shared code compiled by build systems with multiple executables?

Visualize call dependencies

Analyze code complexity

Supporting ISO 26262 ASIL D software verification for EasyMile

IMPASA - Improving Aerospace Software Assurance

SKY AI CONNECT: Advanced Computing and Intelligent Aerospace Technologies

Certification Together International Conference

Aerospace Tech Week Europe 2023

Why mitigating interference alone isn’t enough to verify timing performance for multicore DO-178C projects

Efficient DO-178C verification - WCET analysis

Danlaw Acquires Maspatechnologies - Expanding Rapita Systems to Spain

Rapita Systems SL

Efficient DO-178C verification - Code coverage

Efficient DO-178C verification - Functional testing

RapiCover’s advanced features accelerate the certification of military UAV Engine Control

Why choose Rapita?

Using RVS to support multicore timing analysis

Webinar: Efficient DO-178C verification - WCET analysis

Webinar: Efficient DO-178C verification - Code coverage

Webinar: Efficient DO-178C verification - Functional testing

Multicore DO-178C Training

Rapita co-authored paper wins ERTS22 Best paper award

Platform Support Packages Order information

Complementary DO-178C verification with Ansys(R) SCADE Test(TM) and RVS

High Integrity Software Conference 2022

There are how many sources of interference in a multicore system?

A look back on Rapita's Multicore DO-178C training in Huntsville

Accelerated verification with RVS 3.17

Out-of-the-box software verification with Deos® and RVS

RVS 3.17 Launched

York Aerospace and Rocketry Society MACH-22 Update

Can I use RapiTask to investigate the scheduling behavior of my code that runs on Deos?

Can I use RapiTime to verify my code that runs on Deos?

Can I use RapiCover to verify my code that runs on Deos?

Can I use RVS to verify my code that runs on Deos?

Can I use RapiTime to support worst-case execution time analysis of code in my SCADE project?

Can I use RVS to test my SCADE model code on target?

Supporting modern development methodologies for verification of safety-critical software

Verifying your Multicore RTOS

Flexible licensing software fit for modern working

Can I create and manage groups for my floating RVS licenses?

ERTS Congress 2024

SYSGO + Rapita: Verifying your Multicore RTOS

A(M)C 20-193 vs. CAST-32A: What the change means for your DO-178C Multicore project

Verifying Multicore Systems supporting the FACE standard - ATW Global 2021

Timing Analysis for Critical Aerospace Embedded Software - ATW Global 2021

A(M)C 20-193 vs. CAST-32A: What the change means for your DO-178C Multicore project

AMC 20-193 and what it means to you

Tool qualification with RVS

Rapita Customer Testimonials

RVS 3.16 Launched

Revolutionized testing with RVS 3.16

Analyzing results from multicore timing analysis

How does RapiTime support multicore timing analysis?

Testing using the RapiTest Editor

Using time bands to apply instrumentation with RapiTime

DO-178C Glossary

Analyze results from multicore timing analysis

Investigate multicore interference effects

Integrated testing format

RVS 3.16 Launched

Air Force FACE and SOSA TIM and Expo

Robust partitioning for multicore systems doesn’t mean freedom from interference

Easily configurable analysis with RVS

DO-178C - Stage of Involvement 4

DO-178C - Stage of Involvement 3

DO-178C - Stage of Involvement 2

DO-178C - Stage of Involvement 1

DO-178C Blog Series: Introduction to DO-178C

Supplementing DO-178C activities for CAST-32A

2021 FACE™ Consortium F2F Meetings

TSAO-ID: Tri-Service Open Architecture Interoperability Demonstration

Aerospace Tech Week Americas 2023

slides.length) { slideIndex = 1 } if (n < 1) { slideIndex = slides.length } for (i = 0; i < slides.length; i++) { slides[i].style.display = "none"; } for (i = 0; i < dots.length; i++) { dots[i].className = dots[i].className.replace(" active", ""); } slides[slideIndex - 1].style.display = "block"; dots[slideIndex - 1].className += " active"; } @media only screen and (min-width: 992px) and (max-width: 1199px) { .prev { margin-left: -50%; } .next { margin-right: 0%; } } @media only screen and (min-width: 639px) and (max-width: 992px) { .prev { margin-left: -60%; } .next { margin-right: -10%; } } @media only screen and (max-width: 639px) { .prev { margin-left: -50%; } .next { margin-right: 0%; } } "> What's in a good qualification kit?

NXP MultiCore for Avionics Conference

Aerospace Tech Week – November 2021

Delivering world-class tool support to Collins Aerospace

How to perform Cost-Effective Multicore Verification

Efficient Verification Through the DO-178C Life Cycle

Supporting Collins Aerospace with DO-178C Enterprise Tool Qualification (RVS)

NASA selects Rapita Verification Suite for the Lunar Gateway

Digital Avionics Systems Conference

slides.length) {slideIndex = 1} if (n < 1) {slideIndex = slides.length} for (i = 0; i < slides.length; i++) { slides[i].style.display = "none"; } for (i = 0; i < dots.length; i++) { dots[i].className = dots[i].className.replace(" active", ""); } slides[slideIndex-1].style.display = "block"; dots[slideIndex-1].className += " active"; } @media only screen and (min-width: 992px) and (max-width: 1199px) { .prev { margin-left: -50%; } .next { margin-right: 0%; } } @media only screen and (min-width: 639px) and (max-width: 992px) { .prev { margin-left: -60%; } .next { margin-right: -10%; } } @media only screen and (max-width: 639px) { .prev { margin-left: -50%; } .next { margin-right: 0%; } } "> York Aerospace and Rocketry Society Update

A Commercial Solution for Safety-Critical Multicore Timing Analysis

FACE Technical Interchange Meeting - September 2021

Is a Platform Support Package available for my platform?

What are Platform Support Packages and why are they needed?

Bell selects Rapita for Invictus 360 FARA Project

Engineering Services Order Information

RapiDaemon DO-178C Tool Qualification Order Information

RTBx Order Information

RVS Acad Order Information

RVS Auto Order Information

RVS Aero Order Information

How does RVS support Enterprise licensing?

My project includes subcontracting organization(s) and I have confidentiality concerns. Can RVS help me?

How does RapiTime support results collection from multiple builds or test runs?

Multicore timing analysis support with RVS 3.15

Verifying multicore hardware and software

Easily migrate to new versions

DO-178B/C qualification kit

Qualified Target Integration Service

ISO 26262 qualification kit

Qualified instrumenters

Assurance issue notification

Introducing the RapiTest Editor

Redact source code for confidentiality

Custom multicore exports

Automatically merge timing results

RVS 3.15 Launched

RVS 3.15 Launched

CAST-32A Compliance Update

Tool automation in multicore timing analysis

Custom multicore exports with RVS

How to verify multicore hardware & software for avionics

Merging timing results with RapiTime

CAST-32A Compliance Update July 2021

Automatically merge timing results

Compliance with the Future Airborne Capability Environment (FACE) standard

Reduce analysis effort through automation

Evaluate and select multicore hardware and RTOS

Characterize and quantify multicore interference

Produce AC 20-193 and AMC 20-193 compliance evidence

Target Integration Service

Capture values from hardware event monitors

Tool Qualification Kits

Qualified Target Integration Service

RapiDaemon Qualification Service

Procedures, templates and checklists

Platform Analysis and Characterization Service

Software Analysis and Characterization Service

Solving DAL-A Safety Certification Challenges for Military Avionics Systems

Testing using spreadsheets in RapiTest

Analysis and injection engine supports diverse verification activities

US export control

Defense avionics

RVS tool integration

Hardware engineering

RVS Proof of Concept study

RapiDaemon Tool Qualification for DO-178C

Software verification of the Solar Orbiter's EPD

5 key factors to consider when selecting an embedded testing tool

Webinar: Solving DAL-A Safety Certification Challenges for Military Avionics Systems

Ecosystem partnerships

Technical working group memberships

RVS tool qualification

Custom tool development

Systems engineering

Software verification and validation

Engineering Services

Compiler verification

Multicore timing analysis

Automated test environments

.nav-link { background-color: #2.nav-pills .nav-link.active, .nav-pills .show>.nav-link { background-color: #2c3584 !important; }c3584 !important; } .wpform, .popup_container, .popup_container2, .popup_container3 { padding: 20px; background-color: white; } /* Flexible iFrame */ .flexible-container { position: relative; padding-bottom: 56.25%; padding-top: 30px; height: 0; overflow: hidden; } .wpform .formheader { padding-left: 0px; } .single-webinar .card .card-img-top { padding: 0px; } .single-webinar .card-body a { color: black !important; } .single-webinar .card-body { min-height: 215px; } @media only screen and (max-width: 992px) and (min-width: 768px) { .card-row .col-md-7 { margin: auto; } } @media only screen and (max-width: 1200px) and (min-width: 992px) { .single-webinar .card-body { min-height: 240px; } } .discoform #edit-download-choice--3--wrapper span { font-size: 20px; } .flexible-container iframe, .flexible-container object, .flexible-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; } .list-group { margin-bottom: 10px; } #dal-table thead th { background: none; } .overlay-image { overflow: hidden; height: 100%; z-index: 2; } .infoitem { margin-top: -10px; } .videoWrapper { margin-top: 60px; } .closepopup1 a, .closepopup2 a, .closebutton a { font-size: 25px; color: black !important; padding-right: 20px; cursor: pointer; } .closebutton { text-align: right; margin-top: -15px; margin-right: -15px; } .jumbotron .display-4 { font-size: 2.5em; padding-top: 25px; } .jumbotron .wp_dw { width: 100%; text-align: center; } #formbox2.active, #formbox.active, #formbox3.active, #formbox4.active { display: flex; justify-content: center; align-items: center; } #formbox, #formbox2, #formbox3.active, #formbox4.active { position: fixed; z-index: 1000; top: 0; width: 100%; height: 100%; background-color: rgba(0, 0, 0, .8); display: none; } .top-bnr { background: rgb(2, 0, 36); background: linear-gradient(112deg, rgba(2, 0, 36, 1) 0%, rgba(44, 53, 132, 1) 35%, rgba(0, 72, 145, 1) 100%) padding: 80px 0 50px 0; } .mesh { background-image: url(../files/mesh_bg.png); background-repeat: no-repeat; } .top-heading h1 { color: white; font-size: 50px; } .doimg { width: 100%; height: auto; } .form-holder { padding: 90px 10px 10px 10px; } .node--type-discovery-page .form-holder .discoform legend span { color: white; } .node--type-discovery-page form-holder .privacy-notice { color: white !important; } .form-holder .discoform .privacy-notice, .discoform .privacy-notice a { color: white !important; } .top-paragraph p { color: white; font-size: 18px; } .top-img { margin-top: -100px; } .white-bnr, .slide-bnr { padding: 50px 0; background-image: url(../files/white_bg.png); background-repeat: no-repeat; background-size: cover; background-position: right; } .grey-bnr { padding: 50px 0; background-image: url(../files/mesh_bg.png); background-repeat: no-repeat; background-size: contain; } .graybg { background-color: #f9f9f9; padding: 50px 0; } .dark-bnr { padding: 50px 0; background: linear-gradient(-8deg, #2c3584, #0e3754 45%, #376789 75%, #2c3584); background-repeat: no-repeat; } .slide-bnr { padding: 10px 0 50px 0; } .dal-cards .card { margin: 10px 0; } .dal-cards .card .card-link { float: right; } .dal-cards .card .card-text { font-size: 1em !important; } .freetrialbtn { background-color: orange; color: white; } .dal-cards .card:hover .card-body { background: linear-gradient(-138deg, #ffa500 0, #f37a20 55%, #ffa500 100%); transition: linear .2s; color: white !important; } .dal-text { color: white; } .dal-text h2 { color: white !important; } .dal-cards .card:hover .card-title { color: white !important; } .dal-cards .card:hover .card-link { color: white !important; } .card-img-top { padding: 0 50px; } #dal-table td { background: none !important; } .highlighted { position: relative; width: auto; height: auto; display: flex; justify-content: center; align-items: center; } .discoform input { color: black; } .highlighted img { width: 100%; height: 100%; } .highlighted:before { content: ""; display: block; position: absolute; top: 0; bottom: 0; left: 0; right: 0; width: auto; height: auto; background: rgba(255, 255, 255, 0.6); } .jumbotron video { padding-top: 60px; } .jumbotron { background-color: #2c3584 !important; background-image: url(/themes/contrib/rapita2020/css/base/bg_wedge.svg); background-size: cover; padding-top: 50px !important; padding-bottom: 50px !important; margin-bottom: 0 !important; } .jumbotron .display-4, .jumbotron .lead { color: white; } .list-group-item.active { background-color: #2c3584 !important; border-color: #2c3584 !important; } .sidebar { width: 50px; transition: linear 0.3s; position: fixed; right: 0; text-decoration: none; color: #fff; border-radius: 0 5px 5px 0; top: 250px; z-index: 99999; } .sidebar .sidebtn { width: 320px; height: 50px; position: relative; right: 135px; top: 135px; margin: 0; border-top-right-radius: 8px; border-top-left-radius: 8px; box-shadow: 0 10px 14px 10px rgb(238 58 36 / 26%); text-align: center; line-height: 40px; transform: rotate(-90deg); -webkit-transform: rotate(-90deg); color: white !important; font-size: 20px; } * { box-sizing: border-box } .mySlides, .wpSlides { display: none } .mySlides img, .wpSlides { vertical-align: middle; border: 1px solid lightgrey; } .fade:not(.show) { opacity: 1; } /* Slideshow container */ .slideshow-container { max-width: 1000px; position: relative; margin: auto; } /* Next & previous buttons */ .prev { margin-left: -40%; } .next { margin-right: 10%; } .prev, .next { cursor: pointer; position: absolute; width: auto; padding: 16px; margin-top: -22px; color: white; font-weight: bold; font-size: 18px; transition: 0.6s ease; border-radius: 0 3px 3px 0; user-select: none; } /* Position the "next button" to the right */ .next { right: 0; border-radius: 0px 5px 5px 0px; } .prev { border-radius: 5px 0px 0px 5px; } /* On hover, add a black background color with a little bit see-through */ .prev:hover, .next:hover { background-color: rgba(0, 0, 0, 0.8); color: white !important; } .slideshow-container:not(.sbutton), .mySlides { text-align: left; } /* Caption text */ .text { color: black; padding: 8px 12px; bottom: 8px; width: 100%; text-align: center; font-size: 0.8em; } /* The dots/bullets/indicators */ .dot, .wpdot { cursor: pointer; height: 15px; width: 15px; margin: 0 2px; background-color: #bbb; border-radius: 50%; display: inline-block; transition: background-color 0.6s ease; } /* Fading animation in slideshow*/ .fade { -webkit-animation-name: fade; -webkit-animation-duration: 1.5s; animation-name: fade; animation-duration: 1.5s; } @-webkit-keyframes fade { from { opacity: .4 } to { opacity: 1 } } @keyframes fade { from { opacity: .4 } to { opacity: 1 } } DO-178 RTCA DO-178C / EUROCAE ED-12C: Software Considerations in Airborne Systems and Equipment Certification is the primary document by which certification authorities such as the FAA and EASA approve civil software-based aerospace systems. Recently, it has become the de facto approach for demonstrating airworthiness in military avionics systems worldwide. Download DO-178C Handbook DO-178C webinar series Introduction Design Assurance Levels DO-178C processes Tool qualification How we help Introduction to DO-178C DO-178 was originally developed in the late 1970s to define a prescriptive set of design assurance processes for airborne software that focused on documentation and testing. In the 1980s, DO-178 was updated to DO-178A, which suggested different levels of activities dependent on the criticality of the software, but the process remained prescriptive. Released in 1992, DO-178B was a total re-write of DO-178 to move away from the prescriptive process approach and define a set of activities and associated objectives that a design assurance process must meet. This update allowed flexibility in the development approaches that could be followed, but also specified fundamental attributes that a design assurance process must have, which were derived from the airworthiness regulations. Many advances in software engineering technologies and methodologies since the release of DO-178B made consistent application of the DO-178 objectives difficult. In 2012, DO-178C/ED-12C was released, which clarified details and removed inconsistencies from DO-178B, and which also includes supplements that provide guidance for design assurance when specific technologies are used, supporting a more consistent approach to compliance for software developers using these technologies. DO-178C guidance also clarified some details within DO-178B so that the original intent could be better understood and more accurately met by developers. Collins Aerospace How RapiCover was used for DAL A code coverage analysis for a complex flight control system. View case study Triumph Group How Rapita's V&V services produced evidence for certification of actuation system software. View case study Cobham Aerospace Rapita tools efficiently produced coverage evidence for DAL C certification of an antenna control unit. View case study OHB Sweden How Rapi Cover improved code coveage analysis for DO-178C attitude orbital control system. View case study Design Assurance Levels DO-178B introduced (and DO-178C continued to use) the fundamental concept of the Design Assurance Level (DAL), which defines the amount of rigor that should be applied by the design assurance process based on the contribution to Aircraft Safety. The higher the DAL, the more activities and objectives that must be performed and met as part of the Design Assurance process because of the more severe consequences to the aircraft should the software fail or malfunction. The five DALs, which are summarized in the table below, determine the amount of rigor required in the development and testing of a specific piece of airborne software. DAL Condition Objectives A Catastrophic 71 B Hazardous 69 C Major 62 D Minor 26 E No safety effects 0 DO-178C processes Planning Development Integral Planning DO-178C planning is the first DO-178C process that should occur and follows the basic design assurance principle that you say what you are going to do before you do it so you can ensure that what you plan to do will meet the required DO-178C objectives and provide evidence to demonstrate this. Development of a set of plans covering all components of the Design Assurance process is a cornerstone of DO-178C. As part of this activity, the following plans must be developed: Plan for Software Aspects of Certification (PSAC): a description of the software you plan to develop, the hardware environment it will be used in, the design assurance processes you will follow, and how you will demonstrate compliance, including how you will verify your implemented code and any commercial tools you will use in your verification. Software Development Plan (SDP): a description of the software development processes and the software life cycle that is used to satisfy DO-178C objectives. Software Verification Plan (SVP): a description of the verification processes (Reviews, Analyses and Tests) used to satisfy DO-178C objectives. Software Configuration Management Plan (SCMP): a description of the methods and environment that will be used to configure all of the design data and compliance evidence needed to achieve DO-178C certification. Software Quality Assurance Plan (SQAP): a description of the methods and associated records that will be used to ensure that DO-178C quality assurance objectives are satisfied. Development Development covers all of the activities that involve design and production of DO-178C software that meets system requirements of the project. This includes definition of high and low-level software requirements, software architecture definition and implementation of the software. Requirements should be developed in order to meet system requirements of the component hosting the software. These system requirements may be decomposed into hardware requirements (DO-254) as well as software components. Requirements should be verifiable as they will need to be verified in order to generate compliance evidence. The software architecture must be designed before the software is implemented. It is worth considering how the software architecture will affect verification efficiency as verification comprises a large proportion of the cost of a DO-178C project. Particularly, it is worth considering how your architecture will affect the efficiency of data coupling and control coupling analysis of your implemented software. Engineers new to DO-178C may be surprised at how small a proportion of overall effort Implementation takes in a DO-178C project, particularly at high DALs e.g. DAL A. As verification is much morwe effort intensive than implementation, it is worth considering how implementation decisions such as choice of language and language constructs used, choice of hardware platform and choice of compiler and compiler options will affect verification efficiency. Integral processes DO-178C includes 4 Integral processes, which are followed throughout a DO-178C project. These are Verification, Configuration Management, Quality Assurance and Certification Liaison. Integral processes should be planned during DO-178C planning. Following the processes should generate evidence that can be provided to certification authorities to demonstrate that you have followed the processes you planned to (and agreed with the certification authority). Verification covers activities needed to demonstrate that DO-178C software functions as intended. You will plan a Verification strategy in your Software Verification Plan and follow this after. Some Verification activities should be achieved by testing, while some are achieved by reviews. Software tools are often used to reduce the effort needed to verify DO-178C software. Configuration Management covers the processes by which you will control and track versioning of items developed during DO-178C projects, including software and documents such as reviews. Your Configuration Management process must generate a record of every version of every item, and these should be accessible throughout the project. Quality Assurance covers activities that demonstrate that you are following the plans and standards that you have said you will follow throughout a DO-178C project. This includes change control, problem reporting and conducting a conformance review to ensure that your DO-178C software and related documents are ready to share with your certification authority in the final Stage of Involvement (SOI). Certification Liaison covers activities in which you will interact directly with your certification authority, including the processes you will follow to prepare for and conduct the DO-178C SOIs with them. The typical process for the certification authority to determine compliance is based on four “Stage Of Involvement” (SOI) reviews/audits. These reviews are: SOI#1 or Planning Review SOI#2 or Development Review SOI#3 or Verification Review SOI#4 or Certification review Each of these reviews focuses on an aspect of the process and evaluates the evidence that demonstrates compliance incrementally throughout the development life cycle. Likely locations of SOI audits during software development Free 70-page handbook download Efficient verification through the DO-178C life cycle This handbook takes you through the whole DO-178C journey with a focus on verification, leaving you with an understanding of the compliance process as a whole and practical tips to efficiently verify DO-178C software. Download now Tool qualification As per DO-178C, you need to qualify any software tool you use that replaces or mitigates any DO-178C process and for which the output is not manually verified. The qualification process ensures that such software tools can be relied upon to produce appropriate and repeatable results. DO-178C itself describes when a tool must be qualified, but does not go into detail on how this should be done. The DO-330: Software Tool Qualification Considerations supplement to DO-178C expands on this guidance by defining corresponding objectives for the specification, development and verification of qualified tools. If you use any commercial verification tools to automate DO-178C verification processes and don’t plan on manually reviewing output from the tools, they will need to be qualified at the appropriate tool qualification level. Many commercial verification tools have supporting qualification kits, which include evidence needed to demonstrate that the activities the tool developer must perform have been performed. All qualification kits should include all of the evidence needed from the tool developer. Some qualification kits may also include supporting material to help meet tool user objectives. How can Rapita help? Verification tools V&V Services Systems engineering A(M)C 20-193 compliance Tool support Training The Rapita Verification Suite (R VS) reduces the effort needed to verify DO-178C software by helping to satisfy specific DO-178C objectives. R VS includes plugins that satisfy requirements-based functional testing, structural coverage analysis and worst-case execution time analysis and is supported by a qualification kit and service to provide DO-330 tool qualification evidence. To see how R VS could help you, contact us or download a free trial today. Our Verification and Validation Services help satisfy DO-178C objectives. We provide services covering the full DO-178C life cycle, supporting efficient Planning, Development, and Integral processes including software verification using R VS. Our engineering team have diverse experience working in civil and defense avionics development and verification worldwide. To see how our V&V Services could help you, download our brochure or contact us. Our systems engineering services, with our emphasis on quality and adherence to ARP4754A industry guidance, support the development of systems with well-designed hardware and software. We support system integration and verification and validation of system requirements. Our automated V&V tools integrate with industry standard requirements management software to capture results while seamlessly maintaining traceability to requirements. Find out more about our systems engineering services. Specific guidance for how DO-178C should be applied to multicore software is available in the A(M)C 20-193 guidance. MACH 178 supports Planning, Development and Integral processes for multicore DO-178C projects, including by support multicore timing analysis, which is widely considered to be the most challenging element of A(M)C 20-193 compliance. To see how MACH 178 could help you, contact us. Our support team is comprised of our Field Application Engineers (FAEs), who use RVS every day and regularly perform integrations involving a variety of compilers, languages, and platforms. Our policy is to always provide our customers with the best level of support we can realistically achieve, and as such we resolve support issues as quickly and effectively as we can. We have a strong history of excellent support and regard this as an essential aspect of our business. For more information on our support service, see our Support web page. We provide training in a range of expert topics, including: DO-178C compliance, Multicore certification and setting up automated test environments. Our training is flexible; we offer both face-to-face and virtual training and offer custom training courses to meet your specific needs. For more information on our training solutions, see our Training web page. DO-178C verification webinar series Functional testing Learn from V & V experts how to manage your functional testing workflow from writing requirements through to producing test evidence from qualified automation tools. Code coverage Explore a range of code coverage topics (MC/DC, object code coverage) and best practices that you can put into practice in your project to obtain 100% coverage. WCET analysis Learn about the different WCET analysis approaches and how to select the best WCET analysis tool to meet the needs of DO-178C. DO-178C handbook preview Read the first chapter The safety assessment processes used in all functional safety domains rely on demonstrating that the probability of system failure that could cause harm is below an acceptable threshold. When a system is made up of mechanical and electronic components, for which the component failure rate is known, the probability of failure for the system can be calculated and achievement of the safety target can be demonstrated. For software, complex systems or electronic hardware, system failures can be caused by design errors (sometimes known as systematic failures) as well as component failures, but there is no agreed way of calculating the failure rate of these design errors. In the aerospace domain, the agreed approach for dealing with design errors is to implement design assurance processes that have specific activities to identify and eliminate design errors throughout the software development life cycle. DO-178 was originally developed in the late 1970s to define a prescriptive set of design assurance processes for airborne software that focused on documentation and testing. Design Assurance Levels (DALs) DO-178B introduced (and DO-178C continued to use) the fundamental concept of the Design Assurance Level (DAL), which defines the amount of rigor that should be applied by the design assurance process based on the contribution to Aircraft Safety. The higher the DAL, the more activities and objectives that must be performed and met as part of the Design Assurance process because of the more severe consequences to the aircraft should the software fail or malfunction. Design Assurance Level A (DAL-A) is the highest level of design assurance that can be applied to airborne software and is applied when failure or malfunction of the software could contribute to a catastrophic failure of the aircraft. The activities and objectives that must be met through the Design Assurance process gradually decrease with each level alphabetically until DAL-E, which has no objectives as there is no consequence to aircraft safety should such software fail or malfunction. Objectives and activities The recommendations given in DO-178 fall into two types: Objectives, which are process requirements that should be met in order to demonstrate compliance to regulations Activities, which are tasks that provide the means of meeting objectives In total, DO-178C includes 71 objectives, 43 of which are related to verification. The number of these objectives that must be met for compliance reduces as the Design Assurance Level of the system reduces. Supplementary objectives and guidance DO-178C introduced three technology supplements to provide an interpretation of the DO-178C activities and objectives in the context of using specific technologies. The three technologies are Model Based Development and Verification (DO-331), Object Oriented Technology and related technologies (DO-332), and Formal Methods (DO-333). Each supplement describes the technology, defines the scope of its use within airborne software, lists additional or alternative activities and objectives that must be met when the technology is used, and includes specific FAQs (Frequently Asked Questions) that clarify objectives and activities relating to the technology. A further supplement was introduced in DO-178C, Software Tool Qualification Considerations (DO-330), which gives guidance on the qualification of tools used in software development and verification processes. This guidance can be applied to any tools, not just those used for software development or verification, for example systems design or hardware development tools, and acts more like a stand-alone guidance document than the other supplements mentioned. Many other documents support DO-178C by providing additional clarification or explanations that can help developers to correctly interpret the guidance and implement appropriate design assurance processes. The Supporting Information (DO-248C) supplementary document includes FAQs relating to DO-178C, and the document is commonly referred to by the title Frequently Asked Questions. In addition to the FAQs in DO-248C, the document provides the rationale for the activities and objectives listed in DO-178C and includes discussion papers that provide clarification on specific topics related to software development and verification. A series of documents produced by the Certification Authorities Software Team (CAST) since the release of DO-178B provided information on specific topics of concern to certification authorities in order to harmonize approaches to compliance. These topics have had a greater scope than just Software concerns, and much of the content in CAST documents has been implemented in guidance updates such as DO-178C, or formed the basis of authority publications, such as A(M)C 20-193 to address the use of multicore processors in avionics and A(M)C 20-152A on the development of airborne electronics hardware. CAST has remained inactive since October 2016 and links to most previous CAST papers have been removed from the FAA’s website........... Continue reading Learn more about DO-178 related subjects How to meet DO-178C objectives How to meet DO-178C objectives Achieving DO-178C objectives. AC 20-193 AMC 20-193 Verifying multicore systems. EUROCAE ED-215 RTCA DO-330 Software Tool Qualification Considerations. EUROCAE ED-216 RTCA DO-331 Model-based development and verification supplement. EUROCAE ED-217 RTCA DO-332 Object-oriented technology and related techniques supplement. DO-178C Handbook Preview ❮ ❯ Efficient verification through the DO-178C life cycle Following DO-178C guidance when developing safety-critical avionics software can be complex, and there are many potential pitfalls along the way. This handbook takes you through the whole DO-178C journey with a focus on verification, leaving you with an understanding of the compliance process as a whole and practical tips to efficiently verify DO-178C software. Download in full window.onload = function() { jQuery(document).ready(function() { jQuery('.footer').addClass('sidetriggeroff'); //pop-up formbox implementation const formbox = document.createElement('div'); formbox.id = 'formbox'; document.body.appendChild(formbox); const formbox2 = document.createElement('div'); formbox2.id = 'formbox2'; document.body.appendChild(formbox2); function showform() { formbox2.classList.remove('active'); formbox.classList.add('active'); jQuery('.popup_container').removeClass('hide'); jQuery('.popup_container').appendTo('#formbox'); } function showform2() { formbox.classList.remove('active'); formbox2.classList.add('active'); jQuery('.wpform').removeClass('hide'); jQuery('.wpform .closebutton').removeClass('hide'); jQuery('.wpform').appendTo('#formbox2'); } jQuery('.sidebtn').on('click', function(e) { e.preventDefault(); jQuery('.wpform').addClass('hide'); formbox2.classList.remove('active'); showform(); }); jQuery('.wp_dw').on('click', function(f) { f.preventDefault(); jQuery('.popup_container').addClass('hide'); formbox.classList.remove('active'); showform2(); }); jQuery('body').delegate('.closepopup1 a', 'click', function(f) { f.preventDefault(); jQuery('#formbox').removeClass('active'); }); jQuery('body').delegate('.closebutton a', 'click', function(f) { f.preventDefault(); jQuery('#formbox2').removeClass('active'); }); }); //handle "How Rapita can help list" jQuery('body').on('click', '.closepopup1 a', function(f) { f.preventDefault(); jQuery('#formbox').removeClass('active'); }); jQuery('body').on('click', '.closeform a', function(f) { f.preventDefault(); jQuery('#formbox2').removeClass('active'); }); jQuery('body').on('click', '.list-group-item', function(e) { jQuery('.list-group-item').each(function() { jQuery(this).removeClass('active'); }); jQuery(this).addClass('active'); }); jQuery('body').on('click', '#l1', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l1').removeClass('hide'); }); jQuery('body').on('click', '#l2', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l2').removeClass('hide'); }); jQuery('body').on('click', '#l3', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l3').removeClass('hide'); }); jQuery('body').on('click', '#l4', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l4').removeClass('hide'); }); jQuery('body').on('click', '#l5', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l5').removeClass('hide'); }); jQuery('body').on('click', '#l6', function() { jQuery('.infoitem').addClass('hide'); jQuery('.l6').removeClass('hide'); }); //function for toggling sidebar button function isIntoView(elem) { var documentViewTop = jQuery(window).scrollTop(); var documentViewBottom = documentViewTop + jQuery(window).height(); var elementTop = jQuery(elem).offset().top; var elementBottom = elementTop + jQuery(elem).height(); return ((elementBottom = documentViewBottom) & amp; & amp; (elementTop = documentViewTop)); } jQuery(window).scroll(function() { if (isIntoView(jQuery('.sidetrigger'))) { jQuery('.sidebar').removeClass('hide'); } }); //turn of sidebar button when on top of page jQuery(window).scroll(function() { if (isIntoView(jQuery('.sidetriggeroff'))) { jQuery('.sidebar').addClass('hide'); } }); //slideshow function var slideIndex = 1; s = document.getElementsByClassName("mySlides"); d = document.getElementsByClassName("dot"); showSlides(slideIndex, s, d); highlightslide(); function plusSlides(n) { s = document.getElementsByClassName("mySlides"); d = document.getElementsByClassName("dot"); showSlides(slideIndex += n, s, d); highlightslide(); } function currentSlide(n) { s = document.getElementsByClassName("mySlides"); d = document.getElementsByClassName("dot"); showSlides(slideIndex = n, s, d); highlightslide(); } // for wp preview var slideIndex = 1; s = document.getElementsByClassName("wpSlides"); d = document.getElementsByClassName("wpdot"); showSlides(slideIndex, s, d); function pluswpSlides(n) { s = document.getElementsByClassName("wpSlides"); d = document.getElementsByClassName("wpdot"); showSlides(slideIndex += n, s, d); } function currentwpSlide(n) { s = document.getElementsByClassName("wpSlides"); d = document.getElementsByClassName("wpdot"); showSlides(slideIndex = n, s, d); } function showSlides(n, s, d) { var i; var slides = s var dots = d if (n & amp; gt; slides.length) { slideIndex = 1 } if (n & amp; lt; 1) { slideIndex = slides.length } for (i = 0; i & amp; lt; slides.length; i++) { slides[i].style.display = "none"; slides[i].classList.remove("active-slide"); } for (i = 0; i & amp; lt; dots.length; i++) { dots[i].className = dots[i].className.replace(" active", ""); } slides[slideIndex - 1].style.display = "block"; slides[slideIndex - 1].classList.add("active-slide"); dots[slideIndex - 1].className += " active"; } function highlightslide() { jQuery(".overlay-image").removeClass("highlighted"); var stage = "#" + jQuery(".active-slide").attr("data-process") + " .overlay-image"; jQuery(stage).addClass("highlighted"); } } "> DO-178C Guidance: Introduction to RTCA DO-178 certification

New paper: Surrogate Applications for Multicore Contention Modeling

Can I collect RapiCover Zero results from tests run by a third-party test framework?

Can I collect RapiCover results from tests run by a third-party test framework?

Can you provide samples of tests written in different RapiTest formats?

FACE Technical Interchange Meeting

Aerospace TechWeek 2021

Can statistical modeling approaches be used to provide support for timing measurements?

Can statistical modeling approaches be used to provide support for multicore timing measurements?

Does AC 20-193/AMC 20-193 guidance apply to platforms with multiple different processors?

Rapita hosts SCADE webinar with ANSYS

Efficient testing with RVS and ANSYS® SCADE® Test™

How do I apply for multicore timing analysis training courses?

Who delivers multicore timing analysis training?

What are the typical class sizes for multicore timing analysis training courses?

Do you provide certificates for completion of multicore timing analysis training courses?

Do you offer custom multicore timing analysis training courses?

Are multicore timing analysis training courses public or hosted just for my organization?

Do multicore timing analysis training courses include practical components?

What will I learn from attending multicore timing analysis training course(s)?

What multicore timing analysis training courses do you offer?

How do I apply for RVS tool training courses?

What are the typical class sizes for RVS tool training courses?

Do you provide certificates for completion of RVS tool training courses?

Who delivers RVS tool training courses?

Do you offer custom RVS tool training courses?

Are RVS tool training courses public or hosted just for my organization?

Do RVS tool training courses include practical components?

What will I learn from attending RVS tool training course(s)?

What RVS tool training courses do you offer?

Has the delivery of your training courses been affected by COVID-19?

How are your training courses delivered?

Do you offer custom training courses?

What types of training course do you offer?

Enabling cost-effective modular avionics with FACE

Efficient testing with RVS and ANSYS® SCADE® Test™ Webinar

slides.length) {slideIndex = 1} if (n < 1) {slideIndex = slides.length} for (i = 0; i < slides.length; i++) { slides[i].style.display = "none"; } for (i = 0; i < dots.length; i++) { dots[i].className = dots[i].className.replace(" active", ""); } slides[slideIndex-1].style.display = "block"; dots[slideIndex-1].className += " active"; } @media only screen and (min-width: 992px) and (max-width: 1199px) { .prev { margin-left: -50%; } .next { margin-right: 0%; } } @media only screen and (min-width: 639px) and (max-width: 992px) { .prev { margin-left: -60%; } .next { margin-right: -10%; } } @media only screen and (max-width: 639px) { .prev { margin-left: -50%; } .next { margin-right: 0%; } } "> Software verification on the Solar Orbiter

How do RapiDaemons support multicore timing analysis?

How long has RVS been used for software verification?

FACE Virtual Technical Interchange Meeting

FACE Virtual Technical Interchange Meeting

RVS 3.14 Launched

Metrowerks CodeTest - How and why to upgrade

Streamlined software verification with RVS 3.14

DO-178C Virtual Workshop

Clear qualification guidance with RVS qualification kits

Optimizing tests to run after code changes with RVS

Easily manage test runs with RapiTest

Generating test templates with RapiTest

How do RVS qualification kits help me throughout the qualification process?

How do RVS qualification kits help reduce review effort?

Can you help me migrate my existing tests so they work in RapiTest?

How does RapiTime help me select the instrumentation to apply to my code?

How does RapiTest help me select which tests to run?

How does RapiTest help me write tests?

How does RVS support multicore timing analysis?

Can I use RapiTest to test my SCADE Test tests on target?

Can MACH178 be used to generate assurance evidence incrementally?

MATLAB® Simulink® MCDC coverage and WCET analysis

Code coverage for space

RVS 3.14 Launched

Leveraging FACE Conformance Artifacts to Support Airworthiness

Do I need to register for support?

How long does my support and maintenance contract last?

How do I request support? 

What’s included in the standard software support and maintenance package?

Which versions of RVS does support and maintenance cover?

Compliance checklists

Template tool user documents

Clear qualification guidance

ANSYS® SCADE®

Migrate tests from other tools

Streamlined qualification material

Easily manage test runs

Multicore timing analysis

Capture values from hardware event monitors

Automatically generate test vectors

Easily analyze multicore performance metrics

MASTECS Project

Propelling the next generation of scientists

Incremental assurance

Continuous verification with RVS and Jenkins

Zero footprint timing analysis with RapiTime Zero

Zero-footprint system event tracing with RapiTask Zero

Zero footprint coverage analysis with RapiCover Zero

Interference channel analysis support for multicore airworthiness certification with RapiDaemons

Another successful DO-178C Virtual Training Course complete

Incremental Assurance of Multicore Integrated Modular Avionics (IMA)

Certifying multicore systems for DO-178C (CAST-32A) projects

DO-178C Virtual Workshop

Assured Multicore Partitioning for FACE Systems

RVS 3.13a released

NXP MultiCore for Avionics Conference

Airborne Safety with FACE™ in the Digital Battlespace

Airborne Safety with FACE™ in the Digital Battlespace

Requirements for zero-footprint RVS analysis

Assured Partitioning for FACE Systems

Rapita partners with EIS to expand reach into South African market

Code coverage for Ada, C and C++

Future Airborne Capability Environment (FACE) F2F Meeting

What is Rapita's Multicore Timing Solution?

Why should I use Rapita's solution?

Can MACH178 help me with certification aspects of my multicore project?

Going above and beyond the quality standards

Do you provide detailed process descriptions to be incorporated into traditional DO-178C planning documents such as the PSAC and SVP?

Airborne Safety with FACE™ in the Digital Battlespace

Embedded Industrial Solutions CC.

System event tracing with RapiTask

eSOL TRINITY hosts Japanese language webinar on execution time analysis with RVS

Software support and maintenance

Generate test templates

Timing analysis during unit testing

Ask the expert: Multicore safety

Execution time analysis with RapiTime

Is cache partitioning helpful or harmful to multicore timing performance?

Day in the life of a Rapita FAE: The New-Starter Experience During COVID-19

FACE Components: Interchangeable but not Equal

How the Operating System Segment fits into the FACE architecture

Safe Use of Multi-Core Processors Seminar

Requirements traceability with RapiTest

Multicore Avionics Certification for High-integrity DO-178C projects

On-target software verification with RVS

Continuous verification with RVS and Bamboo

Cobham Aerospace Connectivity: RapiCover continues to deliver on the most challenging targets

Justifying untestable code with RapiCover

Merging coverage from different builds with RapiCover

Merging coverage from multiple tests with RapiCover

Functional testing with RapiTest

RVS 3.13 Launched

Achieving robust timing requirements with earlier WCET analysis

Tool integration

Analyze interference in multicore systems

Surrogate RapiDaemon tool

Porting and customization

Verify hardware event monitors

Tuneable RapiDaemons

Advanced RapiDaemons

Standard RapiDaemons

Understand program scheduling behavior

Analyze execution time behavior

Structural coverage analysis

Requirements-based and functional testing

Structural coverage analysis with RapiCover

RVS 3.10 Launched

Streamlined software verification with RVS 3.8

RVS 3.9 launched

RVS 3.11 Launched

RVS 3.12 Launched

Generating low level tests from system tests

Evolving language support in RVS: Libadalang

Zero-footprint coverage analysis with RapiCover Zero

Zero-footprint RTOS event tracing with RapiTask Zero

Zero-footprint execution time analysis with RapiTime Zero

DO-178B Level A Embraer FCS

Multicore Timing Analysis for DO-178C

Automating WCET Analysis for DO-178B & DO-178C

Seven Roadblocks to 100% Structural Coverage (and how to avoid them)

Three steps to avoid software obsolescence in avionic systems

Eight top code coverage questions in embedded avionics systems

CodeTEST™ Replacement with RVS

MASTECS: Multicore analysis service and tools for embedded critical systems

HICLASS: Enabling Development of Complex and Secure Aerospace Systems

SECT-AIR: Software Engineering Costs and Timescales – Aerospace Initiative for Reduction

P-SOCRATES: Parallel SOftware framework for time-CRitical mAny-core sysTEmS

FRESCOR: Framework for Real-time Embedded Systems based on contracts

How are RapiDaemons licensed?

What do I get when I get access to RapiDaemons?

Do you have a standard set of RapiDaemons for my hardware?

Do I need to use RVS tools to use RapiDaemons?

How do I use RapiDaemons?

How do I know when my testing is complete? How much is enough to satisfy AC 20-193/AMC 20-193?

Do you support the analysis of GPU-based architectures for multicore timing behavior?

Have you performed platform analysis for my multicore platform?

How long does it take to comprehensively analyze the interference channels present in multicore platforms?

Is there a standard list of interference channels that I should test?

Have projects supported by MACH178 completed FAA or EASA certification?

How can MACH178 help me with multicore compliance?

What is MACH178?

How do I verify my software’s functional and temporal behavior when instrumentation has been applied?

How do I verify my software’s functional and temporal behavior when instrumentation has been applied?

How do I verify my software’s functional and temporal behavior when instrumentation has been applied?

Can I use RVS tools with my continuous integration environment?

How does RapiTest support my traceability workflow?

Best usage guidance

Qualified instrumenters

Tool qualification licensing

Qualified Target Integration Service

Tool qualification for DO-178 and ISO 26262

DO-178B/C qualification kit

ISO 26262 qualification kit

RTOS-independent scheduling visualization

ReqIF format requirements

Scripting format

Spreadsheet format

RVS 3.13 Launched

Digital Avionics Systems Conference

DO-178C Virtual Training

Software Verification Services

Multicore Timing Solution

500){ jQuery('.floatingbtn').show(); } else { jQuery('.floatingbtn').hide(); } }); */ //put components in appropriate dropdown list jQuery('.pspdetails').appendTo('.detailholder'); jQuery('.psp-item').each(function(){ var psp_text = jQuery(this).text().split(","); var option = jQuery(''); option.attr('data-state',psp_text[2].trim()); option.attr('value',psp_text[1].trim()); option.text(psp_text[1]); option.addClass(psp_text[0].trim()); jQuery('select.'+psp_text[0].trim().split(" ")[0]).append(option); }); //check the decisions made var choices = [0,0,0,0,0]; //ensure someone only selects a debugger/simulator jQuery('.questions .Debugger').change(function(){ jQuery('.questions .Simulator').val("default"); choices[3] = 0; }); jQuery('.questions .Simulator').change(function(){ jQuery('.questions .Debugger').val("default"); choices[2] = 0; }); jQuery('.questions select').change(function(){ var position = jQuery(this).attr('data-position'); if(jQuery(this).find(":selected").attr("data-state") == "Already available"){ choices[position] = 1; } else { choices[position] = 0; } }); function reveal(){ var occurences = jQuery.grep(choices, function (elem) { return elem === 1; }).length; var response = ""; jQuery('.response p').remove(); setTimeout( function() { if (occurences == 4){ jQuery('.responseA').clone().appendTo('.response'); jQuery('.response').addClass("responseshow"); } else if (occurences > 0){ jQuery('.responseB').clone().appendTo('.response'); jQuery('.response').addClass("responseshow"); } else { jQuery('.responseC').clone().appendTo('.response'); jQuery('.response').addClass("responseshow"); } }, 800); } jQuery('body').on('click','.find-psp',function (e) { e.preventDefault(); if (jQuery('.detailholder .form-success').length == 0){ jQuery('#edit-compiler').val(jQuery('.questions .Compiler option:selected:not(:disabled)').text()) jQuery('#edit-instruction-set').val(jQuery('.questions .Instruction option:selected:not(:disabled)').text()) jQuery('#edit-debugger').val(jQuery('.questions .Debugger option:selected:not(:disabled)').text()) jQuery('#edit-simulator').val(jQuery('.questions .Simulator option:selected:not(:disabled)').text()) jQuery('#edit-rtos').val(jQuery('.questions .RTOS option:selected:not(:disabled)').text()) jQuery('.detailholder .submit-form').click(); } reveal(); }); }); } Zero-footprint event-level scheduling analysis for critical software Why choose RapiTaskZero? Gain insight into your application through scheduling analysis Locate rare timing events that need attention Identify bottlenecks in your application by analyzing capacity issues Compare scheduling algorithms from different RTOSs Visualize scheduling behavior of libraries without source code Request a demoCheck PSP compatibility "> RapiTaskZero

500){ jQuery('.floatingbtn').show(); } else { jQuery('.floatingbtn').hide(); } }); */ if (window.location.href.indexOf("/layout") > -1){ jQuery('.hide').show(); jQuery('div').removeClass("hide"); jQuery('div').removeClass("invisible"); alert("we're here"); } //put components in appropriate dropdown list jQuery('.pspdetails').appendTo('.detailholder'); jQuery('.psp-item').each(function(){ var psp_text = jQuery(this).text().split(","); var option = jQuery(''); option.attr('data-state',psp_text[2].trim()); option.attr('value',psp_text[1].trim()); option.text(psp_text[1]); option.addClass(psp_text[0].trim()); jQuery('select.'+psp_text[0].trim().split(" ")[0]).append(option); }); //check the decisions made var choices = [0,0,0,0,0]; //ensure someone only selects a debugger/simulator jQuery('.questions .Debugger').change(function(){ jQuery('.questions .Simulator').val("default"); choices[3] = 0; }); jQuery('.questions .Simulator').change(function(){ jQuery('.questions .Debugger').val("default"); choices[2] = 0; }); jQuery('.questions select').change(function(){ var position = jQuery(this).attr('data-position'); if(jQuery(this).find(":selected").attr("data-state") == "Already available"){ choices[position] = 1; } else { choices[position] = 0; } }); function reveal(){ var occurences = jQuery.grep(choices, function (elem) { return elem === 1; }).length; var response = ""; jQuery('.response p').remove(); setTimeout( function() { if (occurences == 4){ jQuery('.responseA').clone().appendTo('.response'); jQuery('.response').addClass("responseshow"); } else if (occurences > 0){ jQuery('.responseB').clone().appendTo('.response'); jQuery('.response').addClass("responseshow"); } else { jQuery('.responseC').clone().appendTo('.response'); jQuery('.response').addClass("responseshow"); } }, 800); } jQuery('body').on('click','.find-psp',function (e) { e.preventDefault(); if (jQuery('.detailholder .form-success').length == 0){ jQuery('#edit-compiler').val(jQuery('.questions .Compiler option:selected:not(:disabled)').text()) jQuery('#edit-instruction-set').val(jQuery('.questions .Instruction option:selected:not(:disabled)').text()) jQuery('#edit-debugger').val(jQuery('.questions .Debugger option:selected:not(:disabled)').text()) jQuery('#edit-simulator').val(jQuery('.questions .Simulator option:selected:not(:disabled)').text()) jQuery('#edit-rtos').val(jQuery('.questions .RTOS option:selected:not(:disabled)').text()) jQuery('.detailholder .submit-form').click(); } reveal(); }); }); } Zero-footprint timing analysis for critical software Why choose RapiTimeZero? Collect timing metrics from systems that produce branch traces Identify code to optimize for worst-case behavior Debug rare timing events Simplify verification through integration with your CI tool Analyze timing behavior of libraries without source code Request a demoCheck PSP compatibility "> RapiTimeZero

500){ jQuery('.floatingbtn').show(); } else { jQuery('.floatingbtn').hide(); } }); */ //put components in appropriate dropdown list jQuery('.pspdetails').appendTo('.detailholder'); jQuery('.psp-item').each(function(){ var psp_text = jQuery(this).text().split(","); var option = jQuery(''); option.attr('data-state',psp_text[2].trim()); option.attr('value',psp_text[1].trim()); option.text(psp_text[1]); option.addClass(psp_text[0].trim()); jQuery('select.'+psp_text[0].trim().split(" ")[0]).append(option); }); //check the decisions made var choices = [0,0,0,0,0]; //ensure someone only selects a debugger/simulator jQuery('.questions .Debugger').change(function(){ jQuery('.questions .Simulator').val("default"); choices[3] = 0; }); jQuery('.questions .Simulator').change(function(){ jQuery('.questions .Debugger').val("default"); choices[2] = 0; }); jQuery('.questions select').change(function(){ var position = jQuery(this).attr('data-position'); if(jQuery(this).find(":selected").attr("data-state") == "Already available"){ choices[position] = 1; } else { choices[position] = 0; } }); function reveal(){ var occurences = jQuery.grep(choices, function (elem) { return elem === 1; }).length; var response = ""; jQuery('.response p').remove(); setTimeout( function() { if (occurences == 4){ jQuery('.responseA').clone().appendTo('.response'); jQuery('.response').addClass("responseshow"); } else if (occurences > 0){ jQuery('.responseB').clone().appendTo('.response'); jQuery('.response').addClass("responseshow"); } else { jQuery('.responseC').clone().appendTo('.response'); jQuery('.response').addClass("responseshow"); } }, 800); } jQuery('body').on('click','.find-psp',function (e) { e.preventDefault(); if (jQuery('.detailholder .form-success').length == 0){ jQuery('#edit-compiler').val(jQuery('.questions .Compiler option:selected:not(:disabled)').text()) jQuery('#edit-instruction-set').val(jQuery('.questions .Instruction option:selected:not(:disabled)').text()) jQuery('#edit-debugger').val(jQuery('.questions .Debugger option:selected:not(:disabled)').text()) jQuery('#edit-simulator').val(jQuery('.questions .Simulator option:selected:not(:disabled)').text()) jQuery('#edit-rtos').val(jQuery('.questions .RTOS option:selected:not(:disabled)').text()) jQuery('.detailholder .submit-form').click(); } reveal(); }); }); }; Zero-footprint coverage analysis for critical software Why choose RapiCoverZero? Collect coverage from systems that produce branch traces Save time with efficient merge and mark verification workflow Simplify verification through integration with your CI tool Collect coverage for libraries without source code Request a demo Check PSP compatibility "> RapiCoverZero

Multicore for ISO 26262 - Demonstrating freedom from interference webinar

Out of the box Solution for Multicore Analysis

Multicore Timing for DO-178 Projects

Verifying Multicore RTOS Partitioning for DO-178C (CAST-32A) Projects

Validation of COTS Ada Compiler for Safety-Critical Applications

Establishing WCET for the Airbus A330 Multi-Role Transport Tanker

CDS gets WCET support for their next-generation custom processor

OHB Sweden: Efficient DO-178C code coverage analysis using RapiCover

Collins Aerospace: DO-178C code coverage analysis

Automating schedulability analysis of on-board software on the Solar Orbiter

Triumph Integrated Systems: DO-178C Verification and Validation

Alenia Aermacchi (Leonardo) M-346

Wide Body Jet Flight Control System

Infineon SafeTCore drivers

BAE Systems Hawk Mission Computer

Flexible test authoring

Execution Time Profile Chart

Automatically merge coverage

Justification templates

Migrate justifications when code changes

Multi-justifications

Justify untestable code

Merge Coverage utility

Configurable export formats

Functional testing

Produce certification evidence

Zero footprint coverage analysis

Source to object code traceability

Filter by scopes

Aggregate Profile Chart

Platform support

Automate testing on host and target

Multicore support

Collect coverage across power cycles

Comprehensive verification toolsuite

Shared integration with instrumentation-based RVS tools

RVS Project Manager

View detailed timing metrics at a glance

Advanced search function

Easily filter results

Invocation Timeline Chart

Floating licenses

Annual licenses

Perpetual licenses

Portable test environments

Configurable export formats

Configurable export formats

Compare reports

Customizable color scheme

Understand scheduling behavior

Locate rare timing events

Analyze system capacity issues

Customizable task colors

Portable justification library

Optimize code for timing performance

Automatically reformat spreadsheet tests

Template integrations

Customizable workflow

Requirements traceability

Software Configuration Management

Efficient integration workflow

Zero footprint system event tracing

Zero footprint execution time analysis

Comprehensive language support

Shared integration with zero-footprint RVS tools

Flexible licensing options

Node-locked licenses

Assurance issue notification

Structural coverage analysis

Compiler extension editor

Optimal Dataset Calculator

Datasets for managing tests

Filter by datasets

Advanced MC/DC analysis

Worst-case execution time analysis

Zero footprint software verification

Lauterbach debugger

Flexible integration strategies

Produce certification evidence

Optimize code for timing performance

Remove coverage from reports

iSYSTEM debugger

Mixed language support

Low target overheads

Clone integration

Compiler wrappers

Integrate with existing build systems

Easily configurable analysis

Efficient integration workflow

OS-only instrumentation

System event tracing

Efficient, configurable analysis

Execution time analysis

Efficient MC/DC target library

Identify tests that hit each element

Highlight missing MC/DC vectors

Legacy testing tool for Ada

Race condition testing

Access private objects

Black box testing

White box testing

Flexible stubbing

Efficient test generation

Web-based manager

Easy to get started

On-the-fly filtering

Automatically timestamp data

Flexible connection strategies

Automated tracing

High-speed continuous processing

Which languages does RapiCover Zero support?

Can I collect coverage data across power cycles and reset sequences?

Can I view my results in the context of my project source code?

How does RapiCover Zero work?

Which platforms and data collection mechanisms do zero-footprint RVS tools support?

Which coverage criteria can I measure using RapiCover Zero?

Can RapiCover Zero collect MC/DC results?

How do I learn more about RapiTask Zero?

Which languages does RapiTask Zero support?

If I have RapiTime or RapiTime Zero, do I still need RapiTask or RapiTask Zero?

How are my results presented?

Can I use RapiTask Zero to analyze the behavior of multicore architectures?

How does RapiTask Zero show OS events such as inter-process communication (semaphores, messages), timers, hardware I/O etc?

Why do I need RapiTask Zero when I have tools from my RTOS vendor?

How does RapiTask Zero work?

What is RapiTask Zero?

How do I learn more about RapiTime Zero?

Which languages does RapiTime Zero support?

How does RapiTime Zero help me investigate timing behavior?

Can I use RapiTime Zero to analyze the timing behavior of multicore architectures?

Which types of timing data does RapiTime Zero report?

How does RapiTime Zero work?

What is RapiTime Zero?

How do I learn more about RapiCover Zero?

How are my results presented?

What happens when I change my code?

Can I add manual configurations that flag my code as being exempt/uncoverable?

How do you support RVS users?

What happens if I encounter an issue while using an RVS tool?

How are RVS products licensed?

How large a code base can RVS tools handle?

What is RapiCover Zero?

How does RapiTask show OS events such as inter-process communication (semaphores, messages). timers, hardware I/O etc?

Which coverage criteria can I measure using RapiCover?

How long does the tool qualification process take?

Do you offer support for projects with a long life cycle?

What if I discover an error in your qualification support?

What if I make a change to my RVS integration after qualification?

What is the scope of your qualification support?

Why is your tool qualification process more complex than that for my other tools?

Can you help me provide all of the evidence I need to qualify RVS for use in my project?

You don’t offer qualification support for using the RVS tool I’m using in my safety context. What can I do?

Which RVS tools do you provide qualification support for?

Which input languages to the RVS tools can be qualified?

What standards do you use for tool qualification?

How do I learn more about RapiTest?

Can I collect coverage incrementally from multiple builds?

What is the RTBx?

Can I determine timing metrics on my target, which has limited RAM and/or ROM?

How does RapiTime help me investigate timing behavior?

How are my results presented?

How are my results presented?

If I have RapiTime, do I still need RapiTask?

Can I only use RapiTask with RapiTime, or can I use RapiTask as a standalone tool?

Why do I need RapiTask when I have tools from my RTOS vendor?

Can I use RapiTask to analyze the behavior of multicore architectures?

How are my results presented?

Which types of timing data does RapiTime report?

How does RapiTime calculate the worst-case execution time of my software?

Can I use RapiTime to analyze the timing behavior of multicore architectures?

In addition to guaranteeing that timing deadlines are met, how else can I use RapiTime?

How do I determine the execution time overhead from instrumenting my source code?

My software is part of a product that must be certified against a safety guideline. Can RapiTime be qualified for use in my project?

Can I determine coverage for a decision containing large numbers of conditions?

Can I collect coverage data across power cycles and reset sequences?

My software is part of a product that must be certified against a safety guideline. Can RapiCover be qualified for use in my project?

What types of testing does RapiTest support?

How do I write tests for use with RapiTest?

What kind of stubbing behavior does RapiTest support?

How many tests can RapiTest run at once?

How are my results presented?

My software is part of a product that must be certified against a safety guideline. Can RapiTest be qualified for use in my project?

Which languages does RapiCover support?

Which languages does RapiTime support?

Which languages does RapiTest support?

Which languages does RVS support?

Can I use RapiTask with my build system?

Learn more about:

DO-178C Guidance: Introduction to RTCA DO-178 certification

Data Coupling & Control Coupling

MC/DC Coverage

Embedded Software Testing Tools

What is CAST-32A?

Check out our videos on:

Rapita Systems - Safety Through Quality

Multicore Avionics Certification for High-integrity DO-178C projects

Streamlined AMC 20-193 compliance with MACH178 Foundations

On-target software verification with RVS

Functional testing with RapiTest