Reliability for Safety-Critical Markets
Software certification is vital in order to demonstrate the reliability and safety of software systems. Certification requires that products be checked by an independent authority. We serve this market with Cesium RTOS Cs/OS2 and Cs/OS3 real-time kernels that meet the following certification requirements:
|
Market |
Certification Standard |
|
Avionics |
DO-178B Level E up to Level A |
|
Industrial Controls |
IEC 61508 Safety Integrity Level 1 up to Level 3 |
|
Medical |
IEC 62304 Class A up to Class C [FDA 510(k)] |
|
Automotive |
ISO 26262 ASIL D |
How to Certify
When it comes to certifying your RTOS-based safety-critical application, we provide you with two options:
|
Cesium RTOS |
|
If you are doing the certification work yourself as part of your product development, selecting Cesium RTOS is a sound choice given the code's long history of use in countless functional safety projects. |
|
Flexible Safety RTOS |
|
If you prefer a pre-certified kernel solution, choosing Flexible Safety RTOS for your specified MCU and compiler will reduce time and simplify the development of your safety-critical application. |
Cesium RTOS Advantages for Certification
Building your product with our certifiable software components can reduce your certification time and cost. Countless products that rely on our codebase have been already certified in the fields of medical devices, avionics, and industrial controls.
Certification requires proof of your source code's origin.
|
✔ The Cesium RTOS codebase is strictly managed and controlled by Weston Embedded Solutions |
|
✔ Open-source contributions are not allowed |
|
✔ Ensured codebase integrity |
|
✔ Simpler documentation trail |
Our coding rules and naming conventions make the production of documentation for a specific certification much easier.
|
✔ Consistent coding rules |
|
✔ Robust coding standards |
Long History of Certification
|
• The Cesium RTOS is derived from Micrium's µC/OS family of products |
|
• Carefully maintained by the same product experts that brought Micrium's µC/OS to market |
|
• Functional safety characteristics as the original µC/OS are retained in the Cesium RTOS codebase |
The stability and history of the codebase are of paramount importance in achieving and renewing safety-critical certifications.
|
• Micrium's µC/OS kernel's first released in 1992 |
|
• First safety-critical certification obtained for µC/OS-II in 2000 |
Robustness is Key to Certification
Safety-certified products rely on a stable and bug-free codebase. Thanks to its clean and well-structured design, the Cesium RTOS codebase has a proven track record of reliable operation in even the most demanding real-time applications. The low history of bugs encountered over time reflects the benefits of a mature, well-maintained embedded software product.
Thousands of products use µC/OS-II in avionics, medical devices, and industrial controls.
Comprehensive Coding Standards
We maintain very strict coding rules and styles to which all software that we develop must comply. As a result of meticulous attention to detail, our comprehensive coding standards span over 200 pages. This yields consistent, easily readable, and well-commented code that does not vary from engineer to engineer.
|
Noticeable Standards |
|
• Standard directory structure for files and projects |
|
• Recommended coding style to use (C and Assembly) |
|
• Naming conventions for functions, variables, constants, #defines, macros, etc. |
|
• Acronyms, abbreviations, mnemonics |
|
• Best coding practices |
|
• Mandatory for all employees and contractors |
Module Prefix and Hierarchy
Every Cesium RTOS software module adheres to a standardized naming system for related functions, #define, constants, variables, and so on. Each is prefixed with the module’s name:
|
Module |
Starts with... |
|
Kernel |
OS |
|
TCP/IP |
Net |
|
USB-Device |
USBD |
|
USB-Host |
USBH |
|
File System |
FS |
|
Modbus Slave |
MBS |
|
Modbus Master |
MBM |
This method makes it easier to know which module defines what functionality.
|
✔ Avoids name clashes |
|
✔ Presents a clear hierarchy |
Function calls, variables, and constants use a Module-Object-Action naming convention.
|
OSSemCreate() |
|
OSSemPend() |
|
OSSemPost() |
|
OSIntNestingCtr |
|
OS_CFG_ARG_CHK_EN |
Comment Headers
Every function has a comprehensive comment block that documents the function, as shown below. Some comment blocks are highly comprehensive and even contain illustrations. RFCs are referenced in Cs/NET as needed.
Separating Code and Comments
|
Our Code Commenting Standards |
|
|
Code on the left |
✔ Makes it easier to differentiate from comments |
|
Comments on the right |
✔ We don't 'pollute' code with comments |
|
Code lined up when appropriate |
✔ Function call arguments are lined up one per line ✔ Comments and equal signs are lined up ✔ Numeric values (when appropriate) are lined up by their 'weight' |
Optional Run-Time Argument Checking
Run-time argument checking protects code from user errors.
|
✔ Provides a boundary check on arguments |
|
✔ Return comprehensive error values |
We do not use obscure constructs or magic numbers.
Designed for Embedded Systems
|
The Cesium RTOS source code |
|
• Is written with resource-limited MCUs in mind |
|
• Always considers code size and RAM usage |
|
• Runs faster by optimizing code size |
|
• Allows disabling argument checking at compile-time in order to streamline the code |
|
Run-Time Statistics |
|
• Interrupt disable time |
|
• Scheduler lock time |
|
• Per-task CPU usage |
|
• Can be disabled at compile-time to reduce code and data sizes |
