28-02-2011, 02:52 PM
presented by:
Shige Wang
Kang G. Shin
[attachment=9228]
Task Construction for Model-Based Design of Embedded Control Software
Introduction
• large embedded control systems
• problem : running such complex software with stringent timing constraints on a resource limited platform
• systematic and automatic construction of runtime tasks from software design models.
• Difficulty :
• transformation of a model in one model-of-computation (MoC) to a model in another while preserving the properties of the original model.
• is not always possible, nor easy.
• Solution :
• MoC supported by the platform always comes with richer semantics than the MoC used for software design.
• our approach : transformation of the models in two specific MoCs
• task construction
• generate individual schedulable OS processes/threads from a software architecture that implements the discretized control functions.
Software Architecture Model
• a set of concurrent transactions
• software components
• their interactions
• e2e information processing flow
Definition 1: transaction
• A transaction is defined as a weighted directed acyclic graph
• loc :a function that uniquely maps a component to a computation device on the target platform
• F : a weight function that maps a component/link to a nonnegative rational number representing the resource demand
• H defines a set of system-level timing constraints of a transaction
Components
• Upon invocation, a component executes a set of predefined functions in a run-to-completion manner, transforms the inputs to outputs, and delivers the result(s) to all of its output ports upon completion of its execution.
• input component : A component without any incoming link
• The beginning of the transaction
• Is triggered by an external signal, i.e. a timer or a data arrival event
• output component :A component without any outgoing link
• The completion of concurrent computations of the transaction.
• directed links: specify the precedence constraints among the components
timing constraints
• invocation rate (ri(Cin)): the frequency at which an input is updated.
• all the input components, and, consequently, all other components, of the transaction must run at the same rate.
• release offset (oi(Cin)): is defined as the distance in time between the start of the transaction’s invocation period and the event/data arrival at cin
• used to model the synchronization among different inputs.
• Deadline(Di(Cout)): bounds the duration from the start of the invocation period to the completion of the output component cout.