CAmkES: Design
The CAmkES architecture provides a component model, standard interfaces and component definitions, standard component and connector implementations, standard services, and support for various architectural patterns and styles suited for embedded systems. All of these are provided as part of the CAmkES framework.
Specifically the CAmkES framework consists of:
- The CAmkES component model
- Languages (IDL and ADL) for specifying components, component interfaces, and system architectures
- Tools that combine programmer-provided component code with generated run-time, stub, and glue code to generate runnable systems from specifications in our IDL and ADL languages
- Integration with the OKL4 environment
CAmkES in context
CAmkES is part of a layered architecture, as shown below:
- At the bottom is the hardware layer. This includes the CPU, memory, bus, and any other devices.
- On top of the hardware layer is the RTOS (Real-Time Operating System) layer. This consists of the L4 microkernel and its root server. Further support such as device drivers, file systems, and network stacks can be added at this layer as well, however, these services are typically implemented as CAmkES components and therefore reside at the system layer instead.
- The CAmkES layer forms the foundation of the component architecture, providing an execution environment and the basic services required to deploy CAmkES components. The core runtime supports static components and component compositions. More advanced component features are provided by extensions that run on top of the core runtime. The extensions are themselves components that make use of the core runtime features.
- Frameworks further extend the functionality of the component architecture by providing components and services specifically geared to particular application domains. For example, a multimedia framework may specify interfaces for codecs as well as provide components that make use of codecs implementing these interfaces.
- Finally, user defined components combine with the underlying layers to form complete applications.
This layered architecture provides a good separation of concerns. For example, many of the services provided at the extension layer are orthogonal to each other and our architecture allows them to be implemented as such. Furthermore, because services and extensions introduce extra overhead, the layered architecture allows the CAmkES user to balance the trade-offs (e.g., of overhead vs. functionality), choosing to use only the features that they can afford.
The CAmkES Model
The key features of the CAmkES component model are:
- a minimal core model
- The core of the CAmkES model provides the minimum functionality required to build static componentised systems. The functionality provided by the core model includes: specification of RPC, event, and dataport interfaces, specification of components, specification of connectors, specification of compositions of components.
- explicit interactions
- In a componentised system making commuincation between components explicit is critical to providing reusable components. As such all communication (including communication through shared data) is explicit in a CAmkES system architecture. This means that components interact with the rest of the system only via well-defined interfaces.
- Furthermore, In CAmkES we have identified that communication between components is a critical part of a reliable and high performance system. As a result, the connectors that implement communication in our model are first-class entities. This means that connectors can be defined, implemented, and reused by system programmers just like components. We call these user-defined connectors.
- low overhead
- The minimal, static, core of CAmkES makes it possible for us to limit the overhead introduced by a component-based design. Our JSS paper describes the low overhead of an early prototype. The flexibility provided by user-defined connectors allows us to further optimise systems based on their specific requirements.
- extensibility of the model and the tools
- While the core provides only a static model, the CAmkES framework is extensible, allowing further functionality to be added as needed. To illustrate this we have extended CAmkES to provide dynamic (run-time) component instantiation and binding. The costs (in terms of space, performance and complexity) for such extra functionality are only paid for in systems where it is required. This is one of the key motivations behind the CAmkES design: don't pay for what you don't need. Our QoSA paper discusses CAmkES extensibility.
- optimisability
- Given that all communication between components is explicit, and that the system developer can influence how that communication takes place, CAmkES provides a lot of space for system-specific optimisations. Such optimisations can range from a reorganisation of the system architecture in order to improve performance based on known best practices or patterns, to system specific implementations of connectors and key components that take advantage of system specific behaviour to optimise performance hot-spots.
- determinism
- Given that many embedded systems are also real-time systems, the CAmkES core has been designed with determinism in mind. This means that the behaviour and performance of components and connectors can be made to be deterministic such that system timing analysis and prediction is possible.