Hybrid System Modeling

Platform based design

Home Work Plan Platform based design

Both of the above implementations of the platform based design strategy fulfill the goals set out for the helicopter system. Legacy code is simply included in the design, subsystems can be swapped or inte-grated, and full knowledge of the system lessens the reliance on testing to guarantee performance. Although we did delve into some of the details pertaining to this particular automation control system, the design strategy pre-sented could be focused to address a different automation control system.

This is a rather revolutionary approach to the design of embedded controllers and could be used as a general paradigm for ANY embedded system. Since this approach is quite new, we expose the content of the work package in details below beyond the limits of the form for work package description. One of the design drivers (helicopter flight control) is used to exemplify the concepts. We have spent much time conceptualizing this approach and we wish to distill the essence of the approach both from a theory point of view and the domains of application. The main actors in this work package are AQUI and UCB.

The principles of platform-based design are used as building blocks because they result in design solutions that perfectly match our goals. The main tenet is that layers of abstractions are precisely defined and fine tuned to allow only relevant information to pass from below to above. Designs built on top of these layers are then isolated from subsystem details that they don't need while they are provided with enough information to fully explore their design space. These layers of abstraction are called platforms.

Consecutive layers, or platforms, are often used together in the design of one system. These different levels of abstraction allow each design space the right amount of information. As a whole, the system can be presented as the combination of a top-level view, a bottom level view, and a set of tools and methods that map between the layers of abstraction. On the bottom is the architecture space. This space includes all of the options available for implementing the physical system. On the very top is the application space, which includes high-level applications for the system and leaves space for future applications. These two views of the system, the upper and the lower, are decoupled. Therefore, instead of interacting directly, the two design spaces meet at a clearly defined interface. The meeting point is displayed as the shared vertex of the two triangles in figure.

The thin middle of this design diagram represents the key idea that all of the detail of the architecture space is not available to the applications. The vertex point is where an abstraction of the architecture space is defined in order to provide only the necessary information to the space above. The architecture space combined with the vertex makes up a platform. The entire set including the top and bottom view and the vertex are the system platform stack.

The design process itself is regarded as a 'meet-in-the-middle' approach. The specifications do not dictate the implementations and neither do the implementations determine the specifications. Instead, the two meet in a successive refinement process and determine the abstraction layer. The focus is therefore on the correct definition of the vertex interface and involves feedback loops. For example, an initial choice of application implementation helps to define the original platform interface. This platform interface in turn dictates what the architecture implementation needs to provide. The architecture space can then be explored to find an implementation that comes closest to satisfying both the vertex and the preset physical requirements. The platform interface may need to be modified and the application design is therefore re-thought. The process may repeat until an appropriate vertex has been defined. At this point, the vertex is a reasonable and well-defined point of contact between the application and architecture spaces. As a result, new applications may be developed to use the same vertex interface and new architecture instances may be explored to support the same platform interface in the future.

The design process for the overall system platform stack described above might recursively involve platform definitions within solely the application space or architecture space. That is, at each step into the design process where a smaller part of the overall system is being developed, a platform-based design strategy should be implemented. In these cases, the application and architecture spaces will need to be redefined to fit the subsystem and the definition of the proper vertex interface is again the focus of the design process. The design building blocks appear simple and intuitive. However, in practice automation control systems are often very detailed. Pursuing a simple, intuitive design strategy requires planning, patience, and discipline. Indeed, the resulting simple design of an inherently complicated and interconnected system is the reward.

To follow the proposed design strategy for automation control systems we start by precisely defining the architecture and application spaces within the system platform stack. On the bottom are the guidelines for the physical robotic hardware. In the case of the helicopter example, the architecture space includes the choice of helicopters, sensors and actuators. On the top is the control law. In our example, system the control law that was previously developed to stabilize and direct the motion of the helicopter is chosen. This use of legacy code saves time, increases reliability, and fits into the design method.

After defining the two spaces, we next explore the implementation of the application, which in this case is the control law. To do this we use the recursive design method and concentrate on the subsystem design of the controller. The result is the formulation and implementation a time based controller on a real time operating system with a well-defined platform interface in between.

The controller application requires certain information from the architecture space. For example, on the helicopter the controller needs the measurements taken during flight by both the GPS and INS sensors. Since the example controller is time based, it further requires that the information is waiting - as opposed to arriving at unspecified times. It also requires a method of outputting the time based control directive to the actuators. The requirements of the control application help to define the platform interface. As a result, the control process can expect its requirements to be fulfilled by interaction solely with the platform.

The next step is to fill in the requirements for the implementation of the platform that presents the abstraction to the controller. A benefit of the design process is that there are many choices for this implementation. However, they all need to present the correct level of abstraction to the controller as well as satisfy the constraints of the system. In the helicopter example, an implementation of simply sending the sensor data straight through the vertex will obviously not work. This implementation would not meet the correct level of abstraction of the controller due to the various data formats, initialization schemes, operations rates, data communication schemes, and data types for different sensors. This problem will not be solved with the use of a few device drivers either. The platform implementation must use specific information about each sensor and actuator to communicate which each device according to its own format, context, and timing requirements. It then needs to convert the sensor information into the format dictated by the platform interface or take the control directive presented by the platform interface and transform it into the type of signal the particular actuator can interpret. In addition to the conversion, the platform must be implemented so that the asynchronous sensor and actuator data is waiting to be used by the time-based controller.

After determining the platform implementation requirements, the next step is to explore implementations that fulfill these requirements. There are many different possible mappings to a platform instance, and we will discuss a few alternatives for the helicopter example. The first option is to use the combination of a data processor, shared memory, and a data-formatting library. The data processor is an independent process, and in the sensing case, it responds to the new sensor data sent over the serial port by the devices.

The data processor simply saves this sensor data to a shared memory space with the sensor specific data format intact. The shared memory space is implemented as a circular buffer and can be accessed by the control program. In this way, the control process above the vertex can grab the sensor data without worrying about the different timing capabilities of each sensor. The controller process then schedules data fusion and control tasks. Within these tasks, the sensor specific data format must be transferred to the format that the platform is supposed to provide. The control process uses the provided data-formatting library to transform the measurements. In the actuation case, the control task computes actuation data in the format dictated by the platform. Then a function from the data-formatting library can be called from within the timed control process' task in order to transform the actuation directive into the signal format that the actuators expect. Finally, the actuation message is sent based on the controller's clock to the data processor, which farms the signal to the actuators as necessary.

The benefit to this approach is that as much of the code as possible is run from within the time-based controller process. This is important since, in this scenario, all of the processes are running on one processor on the helicopter. Furthermore, in this design the control process provides time-based guarantees about the deadlines of its own internal tasks. The controller process, of course, cannot take into account the time that may be needed by other processes. If more than a 'negligible' amount of time is spent in the other processes then the timing guarantees of the control process may cease to be valid. Therefore, it is best to keep those times to a minimum. As we described about the implementation above, at least one extra process in necessary in order to bridge the asynchronous sensors and actuators to the time-based controller. The main benefit of the above design is that this extra process, the data processor is kept to a bare minimum. The data transformations necessary are instead written into the data-formatting library and called from within the control tasks.

This implementation stems from the platform-based design structure. However, it can be argued that it does not adhere to a strict separation of the control from the sensor details since the library functions are run from within the controller. These library functions were, as mentioned, deliberately included in the controller and should not be run as a separate process on the single processor. However, a second implementation option would be to include two processors on the helicopter. The data processor and the data-formatting library could be combined and placed on the second processor. In this implementation, the separation principle is strictly followed, and the control process can still guarantee the timing of its tasks. There is a tradeoff however. The downside to this second approach is an added amount of latency that is introduced between the time the sensor readings are taken and the time the control laws use the measurements. This increase in the staleness of the data is a common trade off with simpler verification and guaranteed performance.

The end-result is that both of the above implementations of the platform based design strategy fulfill the goals set out for the helicopter system. Legacy code is simply included in the design, subsystems can be swapped or inte-grated, and full knowledge of the system lessens the reliance on testing to guarantee performance. Although we did delve into some of the details pertaining to this particular automation control system, the design strategy pre-sented could be focused to address a different automation control system.