Is an RTOS needed?

Does the RTOS meet the objectives of DO-178C (or DO-178B) and is the supporting life cycle data available to show compliance?

Will the necessary data be provided? If not, will the data be available to support certification and continued airworthiness? FAA Advisory Circular 20-148 lists typical data that are provided with a certifiable component.

How complex is the RTOS?

Are there sufficient data to support the required level of criticality?

If the RTOS was reverse engineered, do the processes satisfy DO-178C objectives (see Chapter 25)?

Have the technical and certification issues concerning RTOSs identified in Chapter 20, as well as any other project-specific issues, been addressed?

Are the typical characteristics and features of an RTOS listed in Chapter 20 implemented? If not, does the missing characteristic or feature impact safety or compliance?

What effect does the RTOS have on the development life cycle of the system that will use the RTOS?

Is the RTOS compatible with other components being developed?

Is this RTOS flexible? Or, does it put constraints on the system under development? If there are constraints, have they been addressed?

In what language and which compiler was the RTOS developed? Does the compiler take advantage of processor attributes, such as out-oforder execution, cache, and pipelines? Is the compiler deterministic?

What tool support does the RTOS offer?

How will the possibility of hardware obsolescence impact the RTOS use?

Will the RTOS supplier support the continued airworthiness requirements for the RTOS (e.g., support throughout the life of the aircraft that uses it)? What will happen if the RTOS supplier goes out of business? Usually, some kind of contract or legal agreement is needed to handle these situations.

What kind of problem reporting system is in place for the RTOS product to support continued airworthiness?

What assurance is there that the RTOS product will not be changed without the user’s knowledge? If it is modified, what process will be used and how will the user be informed?

Has an accurate User’s Manual been produced? Does it address the needs of multiple users? Or, is it tailored for each user?

What application program interface (API) is used? Does the API support portability? Does the RTOS offer comprehensive support for the API?

What configuration management and software quality assurance processes were used in the RTOS development? Are these processes adequate for the system using the RTOS? Are these processes compatible with the configuration management and software quality assurance processes of the system using the RTOS?

Does the RTOS scale when adding tasks?

Is the run-time number of tasks limited? If so, is the upper limit adequate to support the user needs?

What types of intertask communication are supported?

Is the time slice adjustable?

Does the RTOS prevent priority inversion?

Does the RTOS support the selected synchronization mechanism?

Does the RTOS allow the user to select the scheduling algorithm? Do the available scheduling approaches support safety?

Are task switching times acceptable?

How does the RTOS handle the following functions: (1) task handling; (2) memory management; and (3) interrupts? Does it do so in a deterministic manner?

How does the RTOS use memory, such as internal and external cache?

Have the following data consistency concerns been addressed: data corruption or loss, erroneous results, and abnormal parameters?

Have common tasking concerns been addressed (including inadvertent termination or deletion, kernel storage overflow, and stack size exceeded)?

Have common scheduling concerns been addressed (including corrupted task control blocks, excessive task blocking by priority inversion, deadlock, spawning tasks that starve central processing unit [CPU] resources, corruption in task priority assignment, service calls with unbounded execution times, and race conditions)?

Have memory and input/output concerns been addressed (such as fragmentation of heap, incorrect pointer referencing, data overwrite, compromised cache coherency, memory locked, unauthorized access to devices, and unmonitored resources)?

Have common queuing problems been addressed in the RTOS (including task queue overflow, message queue overflow, and kernel work queue overflow)?

Have interrupt and exception concerns been addressed in the RTOS (such as interrupts during atomic operations, no interrupt handler, no exception handler, and improper protection of supervisor task)?

If the RTOS is used to support partitioning/protection, have memory, input/output, and time partitioning/protection issues been addressed (see Chapter 21)?

Has extraneous, dead, or deactivated code been addressed in the RTOS? In particular, how are unused parts of the RTOS being addressed in the requirements?

Does the RTOS or system have a health monitor? Do the recovery mechanisms from problems meet the system safety needs?

How has the data and control coupling analysis been addressed? Does it meet DO-178C Table A-7 objective 8?

Is the kernel abstracted from the hardware in order to support portability onto other targets?

If the RTOS is a commercial off-the-shelf (COTS) product, have the typical concerns of COTS software been addressed (see Chapter 24)?

Have the potential vulnerabilities of the RTOS been identified? Is the mitigation of any vulnerabilities that are not mitigated by RTOS design straightforward and feasible for the integrator/user?

Is there a data sheet that summarizes the RTOS characteristics, limitations, available certification data, etc.? Is the approach for calculating the characteristics and limitations in the data sheet documented?

Is the RTOS timing performance identified (such as latencies, thread switch jitter, scheduling schemes, and priority levels)?

Who will be developing the board support package (BSP) and device drivers? Does the development team have the right information to perform this task?

Are development kits available to assist the RTOS integration? Many RTOS vendors provide kits to help tailor the RTOS, develop drivers, develop BSPs, etc.

Is the RTOS easily configured for specific use or does it require considerable customization?

Was the RTOS developed for use with a specific processor or processor family?

Are the RTOS and CPU(s) interfaces well understood?

Is the RTOS effect on worst-case execution time effectively calculated?

Is the source code available for scrutiny by higher criticality level application developers if needed to support low-level functionality?

Which hardware resources does the RTOS affect?

What effect does the software used to isolate the RTOS from the target computer (such as BSP or device drivers) have on the system certifiability?

Which tools are available for analyzing the RTOS performance, and can these tools verify deterministic behavior?

Are tools for remote diagnostics available? Many RTOS suppliers also provide tools that can help analyze a system’s behavior and support analysis and testing activities.

Does the RTOS have security capabilities that conflict with the system safety objectives? If so, how will these be addressed?

Does the CPU have an internal memory management unit, and does it support partitioning?

How is data and control coupling between the RTOS and the applications handled?