Lynx participated in this year’s Arm TechCon with a booth in the expo hall, where we demoed Lynx MOSA.ic™ and its components — LynxSecure®, Buildroot Linux, LynxOS-178®, and Lynx Simple Applications (which are bare-metal apps). It was great to see people walk down the hallways and stop in the aisle to examine the Automotive demo and Industrial demo.
The concepts behind the demos apply across multiple industries and use cases; we simply chose to highlight these concepts in the context of these two markets for the purpose of putting together the demos. For more information on the Automotive demo, you can read Chris Barlow's blog post. Below you can see a close-up of the architectural graphic shown on the notebook’s screen:
The industrial automation demo shows how a robotics system might conceptually be designed. There are two types of users to the system – an operator that can run, send commands to, and control the robot’s actions; and an administrator that also has the authority to update the robot’s control applications. The domains that have been created to facilitate their use cases are:
The three domains are also connected by a set of data flows, or connections.
The fundamental concepts we are illustrating with the architecture of the industrial automation demo are:
Let’s look at each of these in turn—
When you use a separation kernel like LynxSecure®, which is the foundational component of Lynx MOSA.ic™, you can greatly simplify your architecture. You can make it more understandable, decompose it into its fundamental units of work, and minimize your trusted codebase.
A separation kernel makes it easier to do a functional decomposition of your design. You don’t have to cram all the functionality you need into one big system. For example, just because you happen to want or need the functionality of Linux for a flexible GUI and network stack, or an RTOS for its real-time responsiveness, you don’t want to be forced to use that single OS for all of your system’s functionality.
Instead, think of each piece of the system as being in its own guest environment. Then ask yourself:
When you iterate through these questions you can break down the functional components of your architecture and get a handle on what you want it to do, and what you need to support that component.
When you decompose your architecture you are then in a position to make your system more comprehensible. Each component will be doing a better defined, and more discrete, piece of work. Each component should be able to operate as a stand-alone component, which helps to eliminate “spaghetti” dependencies.
In the industrial automation demo, there are three domains: an operator domain where the authentication/authorization software and network connection reside (if desired, this domain could be further decomposed); an update guard domain; and a trusted robot control domain. Within the trusted robot control domain, there is even further functional decomposition that has been done.
Each component serves its unique purpose. Each component has its communication channels well defined. Each component only communicates via passed messages, so the interdependencies are minimal and each component’s implementation is clean and easily understood.
What is a trusted codebase? In a security context, it’s determined by the security level that the component must reach. For example, whether a component has to work at a security level that is secret or top secret. In a safety-critical context, it’s determined by the safety-criticality level that the component must achieve. For example, whether a component has to work at DO-178C DAL C, or DAL A.
A benefit of decomposing your architecture with a separation kernel is the ability to minimize your trusted codebase. For example, you don’t want to be forced to safety certify all of your system to DO-178C DAL A if most of it is only DAL C. That’s just a waste of time and money.
Decomposition will also help you figure out the right type of operating environments for your required functionality. If you need to do something in real-time, then use an RTOS for the component that needs it. If you need a general purpose OS (e.g. Windows or Linux) to easily create a GUI or for a high-speed network stack, then make that a component. You don’t have to shoehorn your GUI into an RTOS if it doesn’t have real-time safety-critical requirements.
In the industrial automation demo, the robot’s control software is intentionally isolated from the rest of the system. The robot control software is the trusted codebase from a safety-critical point of view. Using a separation kernel to isolate those components, we don’t have to do a safety certification on the component that has the network connection or the authentication/authorization software - it’s not part of the trusted, safety-critical real-time domain.
There’s an abundance of literature and research available on the Internet about why you want to use a least-privilege architecture. We're not going to be able to rehash all that in a blog post like this one. What we would like to point out, however, is that by using a separation kernel and decomposing your functionality, you make it easier to identify and isolate the components of your system and the privileges that each component needs. If you only assign the privileges to the decomposed system components that each needs to do its job, then you can more easily create a least-privilege architecture.
In the industrial automation demo, the components in the robot control domain do not need a network stack (which is a huge attack surface), and access to the protected authentication/authorization keys is not needed either. The operator’s domain does not need the privileges to stop, update, and restart the guests in the robot control domain, and does not need access to any of the robot’s controls. The update guard component only needs access to its FIFOs and shared memory resources to orchestrate the updating of the LSAs. It does not need access to a network stack, authentication/authorization keys, or the robot’s controls.
Whether or not you need an RTOS for your safety-critical needs is an important consideration. In the industrial automation demo, we decided that we didn’t actually need an RTOS. Instead, we used a stack of Lynx Secure® Applications (LSAs) — which are bare-metal applications — to control the robot. The stack of LSAs are controlled by a flexible scheduler (Lynx’s “Z-Scheduler”) which donates CPU time to the decomposed robot control functionality. As mentioned earlier in this blog post, Chris Barlow’s blog post on the automotive demo in our Arm TechCon booth describes LSAs quite nicely.
Arm TechCon was a great show this year. We had the opportunity to show both an industrial automation demo with a moving robot arm and an automotive demo with a live model car driving on virtual roads. Both of those demos highlighted the need for safety-critical and security-critical architectures. If you have a safety-critical and/or security-critical system you need to create, then please contact us at inside@lynx.com or simply click the Get Started button below. We’d love to talk to you about your project and possibly schedule a free whiteboarding session.
About Us
Lynx Software Technologies is dedicated to crafting software platforms founded on simple, elegant architectures that adapt to evolving hardware while balancing the need to preserve hosted application compatibility with open standard APIs.