Componentization for improved reliability and reduced development cost/time/risk

Componentization use case

Using OKL4 as a secure decomposition platform reduces development time and increases reliability. OKL4 uniquely enables an incremental approach to componentization by providing flexible options for the granularity of components.

Since many embedded systems now include hundreds of thousands to millions of lines of code, most development teams have become very familiar with the challenges of all this complexity. Partitioning a complex problem into a set of related but less complex problems is a proven practice in many endeavors, including software development. Decompose a complex software system into a number of less complex subsystems with each subsystem isolated in its own protected execution domain and you have a system that is easier to develop and maintain. Decomposition strengthens fault isolation and makes each subsystem less complex. Both factors make for systems that are more reliable.  Changing the complexity and fault isolation profile of the design not only makes it more reliable as shipped but also makes it easier to debug during the development process.

A framework such as OKL4, which allows communication and interaction between isolated software subsystems, enables this concept to be put into practice in embedded development. OKL4 provides a low barrier to the use of virtual machines for initial coarse partitioning. Of course, in an embedded system, each of these virtual machines now contains part of the whole, making high-speed communication between virtual machines essential to maintaining performance.

The overhead associated with the inclusion of a full operating system in each virtual machine limits this approach as an easy first step towards the componentization of complex software. Since OKL4 is a microkernel-based system software framework, and not just a hypervisor, it also provides lightweight execution environments. These lightweight environments can be tailored to provide only the services needed by their guest application. This significantly reduces the overhead involved in partitioning, which in turn allows it to be applied with a finer level of granularity. Since the services needed by the guest are built up from a minimal microkernel rather than by trying to strip down a full-featured operating system, the result is a much lighter weight solution.

When used to partition complex software applications into less complex components, OKL4 has the following benefits:

• Complex software systems that are easier to develop, debug, and maintain as the result of improved fault isolation and composition from less complex components
• An easy to adopt incremental approach to componentization provided by the flexibility of the OKL4 framework, which supports a choice of granularity from complete virtual machines with full guest operating systems to individual device drivers
• High levels of system performance can be achieved in this configuration, largely as a result of OKL4’s high performance inter process communication (IPC)
• Design flexibility and reliability is also increased by OKL4’s flexible device handling infrastructure, which allows devices to be shared by multiple virtual machines. The virtual machine resides either within an operating system environment or in an isolated and protected domain of its own.
• Reduced development time as the result of better fault isolation. This cuts the time required to track a problem back to its source. For example, developers using OKL4 have highlighted the use of device driver isolation in OKL4 as a way to save significant time debugging
• As componentization is implemented, it not only makes complexity more manageable but also supports improvements to security, based on control over communication privileges among components.
  
  
  • A future release of OKL4 will allow you to implement control of communication privileges easily within the system at a low level of granularity. For example, you will be able to allow communication between a specific Linux Daemon and a “required secure” service running in a separate and protected domain while otherwise preventing communication between the Linux environment and that service.
  
  

Join the Community: OK Developer Mailing List

Back To Top

< < View All Case Studies