• Calendar

December 2, Wednesday
12:00 – 13:30

Modern software engineering heavily relies on clearly specified interfaces for separation of concerns among designers implementing components and programmers using those components. The interface of a component describes the functionality and constraints on the correct usage in a succinct manner. The need for interfaces is evident for assembling complex systems from components, but more so in modern control applications where a network of sensors and actuators is deployed to achieve complex control objectives. The notion of an interface for a control component must incorporate information about timing and resource needs, information that is not represented in current programming interfaces.

In the talk, I'll propose formal languages as an interface for resource sharing and timing. For example, imagine two components that share some resource (e.g. CPU), allocated in a time-triggered manner. With the proposed interface, each component specifies a formal language over the alphabet ${0,1}$ of ``safe schedules", i.e., if $w=w(1),w(2),…$ is in this languages, and the component gets the resource in every time slot t for which $w(t)=1$, then the component meets its performance requirements. The main advantage of this interface is that it allows modular analysis of each component and, then, constraints can be combined using languages intersection.

I'll present theoretical results concerning applications of the above approach to software control systems (where controllers are implemented by a software that shares resources). I'll also introduce a Real-Time-Java based tool, called RTComposer, that supports the proposed methodology. In RTComposer, scheduling specifications can be given as periodic tasks, or using temporal logic, or as omega-automata, or stability requirements. Components can be added dynamically, and non-real-time components are allowed. The benefits of the approach will be demonstrated and applications to wireless sensor/actuator networks based on the WirelessHART protocol and to distributed control systems based on the Control Area Network (CAN) bus (used, e.g., in automotive applications) will be discussed.