Embedded Systems: Programmable Logic -> Reusable models trim software costs

In this architecture, components are designed and used as building blocks for integration, each of which is modeled with event-based external interfaces, a control logic driver and service protocols. The behavior of each component is specified as a finite-state machine (FSM) and the integrated behavior is modeled as a nested finite-state machine (NFSM). These behavior specifications can be packed into a control plan program and loaded to a run-time system for execution or to a verification tool for analysis.

Specifications in a control plan are directly executable so that the design-phase simulation and debugging are supported. With this architecture, embedded software can be constructed by selecting and then connecting components in an asset library, specifying their behavior and mapping them to an execution platform. Integration of heterogeneous implementations and vendor neutrality are also supported.

An evaluation based on machine-tool-control software development using this architecture has shown that it can reduce development and maintenance costs significantly and provide high degrees of reusability and reconfigurability.

Agile and low-cost software development for real-time embedded systems has become critically important as embedded systems and devices are being used widely and customized frequently. However, the current practice in embedded software development relies heavily on ad hoc implementation and labor-intensive tuning, verification and simulation to meet the various constraints of the underlying application, meaning high development and maintenance costs. < /P>

Although component-based software development and integration are efficient for software development, such an approach is neither well defined nor well understood in the embedded real-time system domain.

Typically, embedded system software consists of various device drivers and control algorithms, which usually exist as software components and are preferred so they can be reused for similar applications. But unfortunately these components may contain dedicated information for some physical processes so they cannot be reused based only on their functions. The physical process for a target domain, on the other hand, is relatively static and can be modeled through component behaviors.

Thus, components can be designed with customizable behavior mechanisms so that they can be reused for different applications. Besides supporting reuse and reconfiguration, the arch itecture for embedded software should support separation of the specification and verification of nonfunctional constraints from those of functions. Such separation is essential for high-level implementation, independent specification and verification of nonfunctional constraints such as timing and resource constraints.

The new architecture supports such features for embedded software integration. The reusable component model separates function definitions from behavior specifications and enables behavior reconfiguration after structural composition. Components can be structurally integrated using their communication ports, through which acceptable external events can be exchanged to invoke target operations. The integrated software can then be mapped onto various platform configurations by customizing service protocols of components.

Behavior of integrated software in our architecture is modeled as NFSMs. The NFSM model supports compositional behavior specifications and supports incremental and formal behavior analysis. Furthermore, since a given behavior can be implemented by different FSMs, different components may be selected for integration to meet different constraints while behaving the same. The behavior specified in other models or languages can be converted to this model using translators.

The integrated behavior can then be specified in a control plan program for remote and run-time behavior reconfiguration. Our architecture also separates other nonfunctional constraints, especially timing and resource constraints, from functionality and behavior integration so that these constraints can be analyzed and verified incrementally and as early as the design phase.

Components are software modules that are implemented beforehand and treated as building blocks in integration. The integrated embedded software can be viewed as a collection of communicating reusable components.

The component structure defines the information required for components to cooperate with oth ers in a system. Our software component is modeled as a set of external interfaces with registration and mapping mechanisms, communication ports, control logic driver and service protocols.

External interfaces define the functionality of the component that can be invoked outside it. In our model, external interfaces are represented as a set of acceptable events with designated parameters. A component with other forms of external interfaces, such as function calls, can be integrated into the system by mapping each of them to a unique event. Using events as external interfaces enables operations to be scheduled and ordered adaptively in distributed and parallel environments and enables components from different vendors (possibly implemented with different considerations) to be integrated into the system without the source code.

Generally, external interfaces are defined as global events, which are systemwide information. An event-mapping mechanism that can be customized is devised in a componen t to translate between global events and the component's internal representations. A registration mechanism is further equipped to perform a run-time check on received events. Only operations invoked by authorized and acceptable events can be performed.

Communication ports are used to connect reusable components-that is, they are physical interfaces of a component. Each reusable component can have one or more communication ports. The number of ports needed for a component can be determined and customized by the system integrator. Different types of ports with different service protocols can be selected to satisfy different performance requirements. Multiple communication parties can share one port.

The control logic driver, also called the FSM driver, is designed to separate function definitions from control logic specifications and support control logic reconfiguration. The FSM driver can be viewed as an internal interface to access and modify the control logic, which is traditionally hard c oded in software implementation. Every component that controls behavior should have an FSM driver inside itself. Control logic of a component can now be modeled as an FSM and be fully specified as a table or a state table. The FSM driver will then generate commands to invoke operations of the controlled objects at run-time according to the state table and the events received.

The FSM driver enables the control logic to be reused, so it solves some cross-cutting design problems of physical process information blended with component behavior. Typically, the behavior of a component is designed to control some physical process and is traditionally hard coded in the implementation of the component tailored to an execution environment. Therefore, the software and the execution platform have to be designed cooperatively. In our approach, since the behavior of a component is separated from its implementation by introducing the FSM driver, the software behavior and the platform configuration can be designed s eparately before integration.

Service protocols define the execution environment or infrastructures of a component. A component can be customized for use in different environments by selecting different service protocols. Such selection is based on the mechanisms available on a platform and performance constraints of the system.

Embedded systems normally deal with mission- or safety-critical applicat ions, so the behavior of software should be thoroughly analyzed before its implementation. In our architecture, the behavior of integrated software is modeled as an NFSM while component behaviors are modeled as traditional FSMs. Both can be formally specified and verified.

Control logic specifications are used to define the static behavior or the control logic of a component. Control logic for integrated software is modeled as an NFSM, which contains a set of traditional "flat" FSMs organized hierarchically. Operation specifications define the desired run-time behavior and can be specified as a programmed operation sequence that will trigger the component actions when there is no other interference. The operation specifications will generate predefined input events for a component FSM at run-time. A program that contains control logic and operation sequences for components is called a control plan. A control plan consists of two parts: logic definitions and operation specifications, corresponding res pectively to the control logic and operation specifications.

Since different subsystems of an embedded system may deal with different physical processes, it is possible that component behavior is expressed in other models. Although the system integration of components in multiple models is being researched and the results are directly applicable to our architecture, we adopt translators to solve the problem of integrating heterogeneous models.

In our architecture a translator is designed and implemented as a software component that converts a specification of a model to a control plan and NFSM. Translators are domain-specific and specification-language dependent, meaning that each translator can convert programs only in a designated specification language to a control plan. Thus, several translators may be required in a system if there are programs written in several specification languages. Software integration includes component selection and binding and control-plan construction (both con trol logic and operation sequence).

The composition model defines how software can be integrated with given components. Since each reusable component is implemented with a set of external interfaces that uniquely define its functionality, components can be selected based on the match of their interfaces and design specifications. The integration of reusable components can be viewed as linking the components with their external interfaces. With such a composition model, both components for low-level control such as algorithms and drivers and for high-level systems can be constructed and reused. However, additional overhead is introduced as the component level is increased and may result in performance penalties due to excessive communication and code size.

The integrated software obtained from the composition model cannot be used directly on a platform since the composition model deals only with functionality. To obtain executable software, components have to be grouped into tasks, which are basic units (that can be scheduled) in current operating systems. Each task must be assigned to a processor with proper scheduling parameters (for example, scheduling policy and priority) determined by an appropriate real-time analysis. Also, communications among components should be mapped to the services supported by the platform configuration.

After these pieces of information are obtained, the components can be mapped to the platform by customizing their service protocols.