Organized in conjunction with MoDELS'08 11th International Conference on Model Driven Engineering Languages and Systems
Workshop Proceedings Table of Contents.....................................................................................................................................3 MultiͲ Level Power Consumption Modelling in the AADL Design Flow for DSP, GPP, and FPGA VTSͲ based Specification and Verification of Behavioral Properties of AADL Models D. Monteverde (Universidad Argentina de la Empresa and Universidad de Buenos Aires, Argentina), A. Olivero (Universidad Argentina de la Empresa, Argentina), S. Yovine (VERIMAGͲ CNRS, France), and V. Braberman (Universidad de Buenos Aires, Argentina) ................................. 23 Translating AADL into BIPͲ Application to the Verification of RealͲ time Systems
M.Y. Chkouri, A. Robert, M. Bozga, and J. Sifakis (VERIMAG, France) ............................................. 39
G.v. Bochmann (SITE, Canada) ......................................................................................................... 55
T.H. Feng and E.A. Lee (University of California, USA) ..................................................................... 71 ISE language: The ADL for Efficient Development of Cross Toolkits
N. Pakulin, and V. Rubanov (Institute for System Programming of the Russian Academy of Sciences, Russia) ............................................................................................................................................... 87 Towards ModelͲ Based Integration of Tools and Techniques for Embedded Control System Design, Verification, and Implementation
J. Porter, G. Karsai, P. Völgyesi, H. Nine, P. Humke, G. Hemingway, R. Thibodeaux, and J.
Sztipanovits (Vanderbilt University, USA) ........................................................................................ 99 Modeling RadioͲ Frequency FrontͲ Ends Using SysML: A Case Study of a UMTS Transceiver
S. Lafi, R. Champagne, A.B. Kouki, and J. Belzile (École de Technologie Supérieure, Canada) ...... 115 From HighͲ Level Modelling of Time in MARTE to RealͲ Time Scheduling Analysis
M.Ͳ A. PeraldiͲ Frati, and Y. Sorel (I3S, France) ................................................................................ 129 A Reinterpretation of Patterns to Increase the Expressive Power of ModelͲ Driven Engineering Approaches
M. Bordin (AdaCore, France), M. Panunzio, C. Santamaria, and T. Vardanega (University of Padua, Italy) ................................................................................................................................................ 145 Foreword The development of embedded systems with real‐time and other types of critical constraints implies handling very specific architectural choices, as well as various types of critical non‐ functional constraints (related to real‐time deadlines and to platform parameters, such as energy consumption and memory footprint). The last few years have seen a growing interest in (1) using precise (preferably formal) domain‐specific models for capturing such dedicated architectural and non‐functional information, and (2) using model‐driven engineering (MDE) techniques for combining these models with platform independent functional models to obtain a running system. As such, MDE can be used as a means for developing analysis oriented specifications that represent the design model at the same time. The objective of this workshop is to bring together researchers and practitioners interested in all aspects of model‐based software engineering for real‐time embedded systems. We target this subject at different levels, from modelling languages and related semantics to concrete application experiments, from model analysis techniques to model‐based implementation and deployment. In particular the workshop focus on the following: • • •
Architecture description languages (ADLs). Architecture models are crucial elements in system and software development, as they capture the earliest decisions that have a huge impact on the realisation of the (non‐functional) requirements, the remaining development of the system or software, its deployment, etc. In particular, we are interested in examining: o the position of ADLs in an MDE approach o the relation between architecture models and other types of models used during requirement engineering (e.g., SysML), design (e.g., UML), etc. o techniques for deriving architecture models from requirements, and deriving high‐level design models from architecture models o verification and early validation using architecture models Domain specific design and implementation languages. To achieve the high confidence levels required from critical embedded systems through analytical methods, specific languages with particularly well‐behaved semantics are often used in practice, such as synchronous languages and models (Lustre/SCADE, Signal/Polychrony, Esterel), time triggered models (TTA, Giotto), scheduling‐oriented models (HRT‐UML, Ada Ravenscar), etc. We are interested in examining the model‐ oriented counterparts of such languages, together with the related analysis and development methods. Languages for capturing non‐functional constraints (UML‐MARTE, AADL, OMEGA, etc.) •
Component languages and system description languages (SysML, BIP, FRACTAL, Ptolemy, etc.). We received 16 submissions from 8 different countries, of which 10 papers were accepted for the workshop. We hope that the contributions for the workshop and the discussions during the workshop will help to contribute and provide interesting new insights in Model Based Architecting and Construction of Embedded Systems. The ACESMB 2008 organising committee, Iulian Ober, Stefan Van Baelen, Susanne Graf, Mamoun Filali, Thomas Weigert, Sébastien Gérard, September 2008. Acknowledgments The Organising Committee of ACESMB 2008 would like to thank the workshop Program Committee for their helpful reviews. This workshop is organised as an event in the context of
The ISTͲ 004527 ARTIST2 Network of Excellence on Embedded Systems Design The research project EUREKAͲ ITEA SPICES (Support of Predictable Integration of mission Critical Embedded Systems) Multi-Level power consumption modelling in the
AADL design flow for DSP, GPP, and FPGA
Eric SENN, Johann LAURENT, and Jean-Philippe DIGUET
Universit´e de Bretagne Sud, Lab-STICC,
CNRS UMR3192,
F-56321 LORIENT Cedex, France Abstract. This paper presents a method that permits to estimate the power consumption of components in the AADL component assembly model, once deployed onto components in the AADL target platform model. This estimation is performed at different levels in the AADL refinement process. Multi-level power models have been specifically developed for the different type of possible hardware targets: General Purpose Processors (GPP), Digital Signal Processors (DSP) and Field Programmable Gate Arrays (FPGA). Three models are presented for a complex DSP (the Texas Instrument C62), a RISC GPP (the PowerPC 405), and a FPGA from Altera (Stratix EP1S80). The accuracy of these models depends on the refinement level. The maximum error introduced ranges from 70% for the FPGA at the first refinement level (only the operating frequency is considered here) to 5% for the GPP at the third refinement level (where the component’s actual source code is considered). 1
Originally coming from the avionic domain, AADL (Architecture Analysis &
Design Language) is now commonly used as an input modelling language for
real-time embedded systems [
Significant research efforts have been devoted to develop tools for power
consumption estimation at different abstraction levels in embedded system design.
A lot of those tools however work at the Register Transfer Level (RTL) (this is
the case for tools like SPICE, Diesel [
In [
We introduced the Functional Level Power Analysis (FLPA) methodology which we have applied to the building of high-level power models for different hardware components, from simple RISC processors to complex superscalar VLIW DSP [18, 19], and for different FPGA circuits [20]. In this paper we show how this modelling approach fits into the AADL design flow and how our power models, being interoperable, are used at different refinement levels. Section 2 presents the AADL component based design flow and the deployment of the Platform Independent Models (PIM) to obtain the Platform Specific Model (PSM) of the target. Section 3 presents the methodology for power estimations and the global power analysis of a complete system described with AADL. Section 4 presents the building of power models and define the three refinement levels where they can be used. The power models of the DSP TI C62, the GPP PowerPC 405, and the FPGA Altera Stratix EP1S80 are presented as examples. The accuracy of our power estimations is finally evaluated. 2
AADL component assembly model AADL models library: - components - interfaces
AADL target platform models: - hw components - services - connectors AADL deployment
plan model AADL PSM model composition SystemC model SystemC C++ code model transformation code generation
HLS/LS/P&R; Compil./Link.
FPGA
DSP
GPP of different plug-ins included in the tool set. During the deployment, software components in the component assembly model are bound to hardware components in the target platform model [22]. According to the deployment plan model, OSATE scheduling analysis plug-in uses information embedded in the software components description to propose a binding for the system [23]. Figure 2 shows the typical binding of an application on a multiprocessor architecture. In this example, process main_process and its data block data_b are bound to the memory sysRAM. Threads control_thread, ethernet_driver_thread and post_thread are bound to the first general purpose processor GPP1. Thread pre_thread is bound to GPP2. Thread hw_thread1 is, like hw_thread2 a hardware thread. It will be implemented in the reconfigurable FPGA circuit FPGA1. One connection between pre_thread and post_thread has been declared using in and out data ports in the threads. This connection is bound to bus sys_bus since it connects two threads bound to two different components in the platform. Intra-component connections, like between threads control_thread and ethernet_driver_thread, do not need to be bound to specific buses. They will however consume hardware resources while being used.
In addition to communication buses, dedicated supply buses can also been declared. A power analysis command in the OSATE resources analysis plug-in permits to check if the power capacity of a supply bus is not exceeded. To do that, a power capacity property (SEI::PowerCapacity) is declared for a bus, and a power budget is declared for every component that requires an access to this bus (property SEI::PowerBudget). The plug-in adds all the power budgets for a bus and compares the result with its power capacity. This mechanism, even if it is interesting, is extremely limited: power budgets for every component are only a guess from the user, and are only used to compute the power consumption sysRAM GPP1 sysCPU1
bus_conn of buses in a very simplistic way. In this paper, we propose a method to greatly enhance power analysis in the AADL flow, and to do it in an efficient way not only for buses, but for every consuming component in the system. Moreover, we propose to base power analysis on realistic power estimates, by using an accurate power estimation tool and precise power consumption models for every component in the targeted hardware platform. 3
In order to complete power consumption analysis for the whole system, we need first to compute the power budget for every software component in the AADL component assembly model. This is the power estimation phase (1) represented with plain edges on figure 3 in the case of the binding of a thread to a processor.
Next, the power budgets of software components are combined to get the power budgets for hardware components. This is the power analysis phase (2) represented with thick dotted edges on the figure. Using timing information, the energy analysis will be performed afterwards (thin dotted edges).
The challenge for our power estimation tool is to provide a realistic power budget for every component in the application. This tool gathers several information in the system’s AADL specification at different places, here from the process and thread descriptions, and from the processor specification. It also uses binding information that may come from a preliminary scheduling analysis. The tool uses the power model of the targeted hardware component (here a processor) to compute the power budget for the (software) component. In fact, it determines the input parameters of the model from the set of information it has gathered. This process is repeated, not only for threads bound to processors, but also for any possible binding of software components onto hardware components, and that means: (i-) threads onto processors or FPGA, (ii-) processes and data onto memories, and (iii-) inter-components connections onto buses.
A process and a thread in the component assembly model Power Models Library
Power Estimation
Tool (1) A processor in the target platform model process1 thread 1 PowerBudget => ? EnergyBudget => ? Once the power budgets have been computed for every component in the application, the power analysis is performed. The power analysis tool retrieves all the component power budgets, together with additional information from the specification, and computes the power budget for every hardware component in the system. Then it computes the power estimation for the whole system. The result of the scheduling analysis (which gives the load of processors) is also taken into account at this level. Indeed, whenever a processor is idle, its power consumption is at the minimum level. Scheduling analysis is performed using basic information on the threads properties defined as properties for each thread implementation in the AADL component assembly model: dispatch protocol (periodic, aperiodic, sporadic, background), period, deadline, execution time ...
This paper will concentrate on the power estimation phase, no further details will be given on the power analysis. Energy analysis will be finally performed using information from the timing analysis tools currently being developed by some of our partners in the SPICES project. 4
Our Power Estimation Tool, PET, is an evolution of the former SoftExplorer, initially dedicated to power and energy consumption estimation for processors (from simple RISC General Purpose Processors to very complex VLIW Digital Signal Processors) [24]. This tool comes with a library of power models for every hardware component on the platform.
Our objective is to allow power estimation at different levels in the flow. This involves the use of multi-level power models, which are models that can be used with more or less information, depending on the refinement level. In fact, while the specification is being refined, more information is available and power estimations get more precise.
Let’s consider a case study platform including one GPP (the PowerPC 405), one DSP (the Texas Instrument C62), and one FPGA circuit (the Xillinx Virtex 400E). The description of those components’ power models can be found respectively in [25], [18], and [20]. Power models are built following our Functional Level Power Analysis methodology [19]. The component’s architecture is firstly analysed and relevant parameters regarding its power consumption are identified. Then physical measurements are performed to assess the evolution of the power consumption with the models’ input parameters (using little benchmarking programs called ”scenario”), and finally power consumption laws are established. 4.1
The TI C62 processor has a complex architecture. It has a VLIW instructions set, a deep pipeline (up to 15 stages), fixed point operators, and parallelism capabilities (up to 8 operations in parallel). Its internal program memory can be used like a cache in several modes, and an External Memory Interface (EMIF) is used to load and store data and program from the external memory [26]. In the case of the C62, the 6 following parameters are considered. The clock frequency (F) and the memory mode (MM) are what we call architectural parameters. They are directly related to the target platform and the hardware component, and can be changed according to the users will. The influence of F is obvious. The C62 maximum frequency is 200MHz (it is for our version of the chip); the designer can tweak this parameter to adjust consumption and performances.
The remaining parameters are called algorithmic parameters; they directly depend on the application code itself. The parallelism rate α assesses the flow between the processor’s instruction fetch stages and its internal program memory controller inside its IMU (Instruction Management Unit). The activity of the processing units is represented by the processing rate β. This parameter links the the IMU and the PU (Processing Unit). The activity rate between the IMU and the MMU (Memory Management Unit) is expressed by the program cache miss rate γ. The pipeline stall rate (PSR) counts the number of pipeline stalls during execution. It depends on the mapping of data in memory and on the memory mode.
The memory mode MM illustrates the way the internal program memory is used. Four modes are available. All the instructions are in the internal memory in the mapped mode (M MM ). They are in the external memory in the bypass mode (M MB). In the cache mode, the internal memory is used like a direct mapped cache (M MC ), as well as in the freeze mode where no writing in the cache is allowed (M MF ). Internal logic components used to fetch instructions (for instance tag comparison in cache mode) actually depends on the memory mode, and so the power consumption.
A precise description of the C62 power model and its building may be found in [18]. The variation of the power consumption with the input parameters, more precisely the fact that the estimation is not equally sensitive to every parameter, allows to use the model in three different situations.
In the first situation, only the operating frequency is known. The tool returns the average value of the power consumption, which comes from the minimum and maximum values obtained when all the others parameters are being made to vary. The designer can also ask for the maximum value if a higher bound is needed for the power consumption.
In the second situation, we suppose that the architectural parameters (here F and MM) are known. We also assume that the code is not known and that the designer is able to give some realistic values for every algorithmic parameter. If not, default values are proposed, from the values that we have observed running different representative applications on this DSP (see table 1).
In the third situation, the source code is known. It is then parsed by our power estimation tools: the value of every algorithmic parameter is computed and the power consumption is estimated, using the power model and the values enter by the user for the frequency and memory mode. α β LMSBV 1024 1 0,625 MPEG 1 0,687 0,435 MPEG 2 ENC 0,847 0,507 FFT 1024 0,5 0,39 DCT 0,503 0,475 FIR 1024 1 0,875 EFR Vocoder GSM 0,578 0,344 HISTO (image equalisation by histogram) 0,506 0,346 SPECTRAL (signal spectral power density estimation) 0,541 0,413 TREILLIS (Soft Dcision Sequential Decoding) 0,55 0,351 LPC (Linear Predictive Coding) 0,684 0,468 ADPCM (Adaptive Differential Pulse Code Modulation) 0,96 0,489 DCT 2 (imag 128x128) 0,991 0,709 EDGE DETECTION 0,976 0,838 G721 (Marcus Lee) 1 0,682
The error introduced by our tool obviously differs in these three situations. To calculate the maximum error, estimations are performed with given values for the parameters known in the situation, and with all the possible values of the remaining unknown parameters. The maximum error comes then from the difference between the average and the maximum estimations. This is repeated for every valid set of known input parameters. The final maximum error is the maximum of the maximum errors. Table 2 gives the maximum error in the three situations above, which correspond to three levels of the specification refinement. Note that the maximal errors computed at level 2 are really pessimistic since we assume here that the designer is completely (100%) wrong on his evaluation of all the input parameters. If his evaluation of those parameters is only 50%, or 25% wrong, then the error introduced by our tool is reduced as well.
The PowerPC 405 is a light version of the IBM PowerPC, embedded in the Xilinx VirtexII Pro FPGA. It includes one prefetch instruction unit that allows to reduce the number of pipeline stalls due to instruction misses, two caches (16KB each) (one for the data and the other for instructions). These two caches can be involved separately and use LRU policy. They are two ways associative with 32 bytes line size. And three TLB translating addresses from logical to physical (2 shadow TLB - one for the instructions and one for data - are used and coupled with an unified one).
Measurements show that among the most important factors in the PowerPC 405 consumption are its frequency and the frequency of the bus to which it is connected. The processor can be clocked at 100, 150, 200 or 300 MHz, and, depending on the processor frequency, the bus (OCM or PLB) frequency can take different values between 25 to 100 MHz. Another important parameter to consider is the configuration of the memory hierarchy associated to the processor’s core, and that means, which caches are used (data and / or instruction) and where is located the primary memory (internal / external). Once again, the component’s power model can be used at three refinement levels.
At the first refinement level, our model gives a rough estimate of the power consumption for the software component, only from the knowledge of the processor and some basic information on its operating conditions. The only information we need is the processor frequency and the frequency of the internal bus (OCM or PLB) to which the processor is connected inside the FPGA. They are two architectural parameters of the PowerPC 405. They will be defined as a property of the AADL processor implementation of the PowerPC 405 in the AADL specification. The maximum error we get here is 27%.
At the second refinement level, we have to add some information about the memories used. We have to indicate which caches will be used in the PowerPC 405 (data cache, instructions cache, or both), and if its primary memory is internal (using the FPGA BRAM memory bank) or external (using a SDRAM accessed through the FPGA I/O). Indeed, while building the power model for the PowerPC 405, we have observed that it draws quite different power and energy in those various situations [25]. Table 3 show the maximal errors we obtain here for every valid set of known input parameters, the others being unknown. The maximum error we obtain is 15,3% and the average error is 6,6%. The first line indicates 0% because in this configuration, there are not remaining unknown parameters that can change the power consumption of the processor. At the lowest refinement level, the actual code of the software component is parsed. In the case of the PowerPC 405, what is important is not exactly what instruction is executed, but rather the type of instruction being executed. We have indeed exhibited that the power consumption changes noticeably from memory access instructions (load or store in memory), to calculation instructions (multiplication or addition). As we have seen before, the place where the data is stored in memory is also important, so the data mapping is also parsed here. The average error we get at this level is 2%. The maximum error is 5%. Logically, that corresponds to the max and average errors for the set of consumption laws for the component. 4.3
FPGA (Field Programmable Gate Arrays) are now very common in electronic systems. They are often used in addition to GPP (General Purpose Processors) and / or DSP (Digital Signal Processors) to tackle data intensive dedicated parts of an application. They act as hardware accelerators where and when the application is very demanding regarding the performances, that typically for signal or image processing algorithms. In this case again power estimation can be performed at different refinement levels.
At the highest levels, the code of the application is not known yet. The designer needs however to quickly evaluate the application against power, energy and / or thermal constraints. A fast estimation is necessary here, and a much larger error is acceptable. The parameters we can use from the high-level specifications are the frequency F and the occupation ratio β of the targeted FPGA implementation, that we consider as architectural parameters, and the activity rate α. The experienced designer is indeed able to provide, even at this very high-level, a realistic guess of those parameters’ value. As explained before, to obtain the model, i.e. the mathematical equation linking its output to the parameters, we performed a set of different measurements on the targeted FPGA. For different values of the occupation ratio, and for different values of the frequency, we made the activity rate varying and measured the power consumption.
At our first refinement level, only the frequency is known. Our power estimation tool uses the model to estimate, at the given frequency, the power consumption with α = β = 0,1 and with α = β = 0,9. Then it returns the average value between those minimal and maximal values. The maximal errors we obtain for F = 10MHz and F = 90MHz (upper bound for the Altera Stratix EP1S80) are given table 4.
At the next refinement level, the two architectural parameters F and β, are known to the user. Like in the case of the former processor’s models, default values are proposed for α and also β, coming from a set of representative applications. The maximal error introduced in this case ranges from 6,9% to 44,8%. To determine this error we compute the maximum and minimum estimations for the four extreme (F , β) couples, and compare them to the estimations with α default value.
At the lowest refinement level, the source code (a synthesizable hardware description of the component behaviour, may be written in VHDL or SystemC ...) is used. A High-Level Synthesis tool [27] permits to estimate the amount of resources necessary to implement the application, and given the targeted circuit, to obtain its occupation ratio (β) and its activity rate (α). Those two parameters and the frequency are finally used with the model. TI C62 property set Processor_Frequency : aadlreal applies to (processor); Processor_Memory_Mode : TIC62::Processor_Memory_Mode_Type applies to (processor); Processor_Parallelism_Rate : aadlreal applies to (processor); Processor_Processing_Rate : aadlreal applies to (processor); Processor_Cache_Miss_Rate : aadlreal applies to (processor); Processor_Pipeline_Stall_Rate : aadlreal applies to (processor); Processor_Memory_Mode_Type : type enumeration (CACHE,FREEZE,BYPASS,MAPPED); Processor_Parallelism_Rate_Default : constant aadlreal => 0,7549; Processor_Processing_Rate_Default : constant aadlreal => 0,5298; Processor_Cache_Miss_Rate_Default : constant aadlreal => 0,25;
Processor_Pipeline_Stall_Rate_Default : constant aadlreal => 0,2919;
As described section 3, the power estimation tool, when it is invoked, extracts relevant information (a set of parameters) from the AADL specification, then computes the components’ power consumption, and returns the results to fill the power budget properties for the software components. The binding makes it possible to put in relation components in the AADL component assembly model with the power models of hardware components on the targeted platform.
As we have just seen, depending on the information refinement, coarse or fine precision power estimations will be performed. Given the refinement level, information to be provided to the estimation tool depends on the selected target (which component). The information is more general if the refinement level is high, it will be more dedicated to the target if the refinement level is low. The set of properties that are used by the estimation tool actually depends on the PowerPC 405 property set Processor_Frequency : aadlreal applies to (processor); Processor_Bus_Frequency : aadlreal applies to (processor); Processor_Primary_Memory : PPC405::Primary_Memory_Type applies to (processor); Processor_Data_Cache : aadlboolean applies to (processor); Processor_Instructions_Cache : aadlboolean applies to (processor); Primary_Memory_Type : type enumeration (BRAM,SDRAM); FPGA Altera Stratix EP1S80 property set FPGA_Frequency : aadlreal applies to (fpga); FPGA_Activity_Rate : TIC62::Processor_Memory_Mode_Type applies to (fpga); FPGA_Occupation_Ratio : aadlreal applies to (fpga); FPGA_Activity_Rate_Default : constant aadlreal => 0,4;
FPGA_Occupation_Ratio_Default : constant aadlreal => 0,5; component itself, and more precisely, on its power model. Even between two components of the same type, another set of specific properties might be necessary since another set of configuration parameters might apply. This is the case here for the two processor components TI C62 and PowerPC405. The property set of the processor comes finally as a part of its power model, and, as this, will remain separated from the general property set associated to the current AADL working project for the application being designed in the OSATE environment. 6
We have presented a method to perform power consumption estimations in the component based AADL design flow. The power consumption of components in the AADL component assembly model is estimated whatever the targeted hardware resource, in the AADL target platform model, is: a DSP (Digital Signal Processor), a GPP (General Purpose Processor), or a FPGA (Field Programmable Gate Array). A power estimation tool has been developed with a library of multilevel power models for those (hardware) components. These models can be used at different levels in the AADL specification refinement process. We have currently defined three refinement levels in the AADL flow. At the lowest level, level 3, the (software) component’s actual business code is considered and an accurate estimation is performed. This code, written in C, or C++, for standard threads, can also be written in VHDL or SystemC for hardware threads. At level 2, the power consumption is only estimated from the component operating frequency, and its architectural parameters (mainly linked to its memory configuration in the case of processors). At level 1, the highest level, only the operating frequency of the component is considered.
Three power models have been presented for the TIC62 GPP, the PowerPC405 GPP, and the Altera Stratix EP1S80 FPGA. The maximum errors introduced by these models, at the three refinement levels, are given table 8. (signalConditioning). The functions are allocated to the Infineon TC1766. In some cases, a behavioural part may have several possible allocations onto different resources. The allocation of a function onto a physical resource implies a temporal cost (the WCET). This cost is a new information that appears on the allocation diagram at the bottom part of each action. Table 1 is a summary of the different temporal characteristics of the behavioural parts. The period, offset and deadline values have been extracted from the behavioural models.
The period expressed initially with the time unit °CRK has been translated in second by applying the time constraint relation on equation 1.
The offset and deadline were expressed as relative dates in the behavioural model with the time unit °CRK. We give in Table 1 the actual values of these parameters obtained by calculating the corresponding values in milliseconds. The last row of the table represents the duration of the deadline which depends on the offset and the deadline date.
WCET (on TC1766 in ms) Period(°CRK - ms) Offset date (°CRK - ms) Deadline date (°CRK / ms) Deadline duration (°CRK / ms)
Knock 0,5 180 - 6,66 24 – 0,888 50 – 1,851 26 – 0,962
Over Temp 0,2 180 - 6,66 0 - 0 50 – 1,851 50 – 1,851
Wam-up 0,2 180 - 6,66 0 - 0 50 – 1,851 50 – 1,851 The WCETs are obtained either by emulating or profiling the tasks corresponding to the correction controllers represented in the behavioural model. The time base in this case is the time base of the processor on which these tasks will execute, i.e. the physical clock. The value of the deadline has been extracted from the book [18] which gives some actual parameters values of an ignition engine controller.
The next step consists in exploiting these characteristics in the scheduling analysis phase. 5 Scheduling analysis 5.1 Principles The scheduling analysis may start as soon as the application models with its associated timing model, and the architecture model, are available. Mainly, it consists in exploiting the timing information, i.e. the temporal characteristics (periods and WCETs, the latter depending on the allocation) as well as the timing constraints (deadlines), attached to each temporally characterized function of the application model. The allocation model allows the designer to determine the actual timing characteristics which vary with the various possible computing resources each application element can be allocated to. Multiple potential allocations can be considered for a function when several computing resources are able to implement it. In our case the computing resource is unique since we address uniprocessor architecture. Nevertheless several versions of this unique processor may be considered. In this case the schedulability analysis must be iterated according to the different processors which induce different timing values of the WCET. The processor of the execution platform is supposed to provide a RTOS, e.g. OSEK in the case of our example. This RTOS is the standard for the automotive domain. The schedulability analysis assumes also that the given RTOS supports the scheduling policy the analysis is based on. This will guarantee that the real-time behaviour of the application, running on the chosen architecture, will satisfy the real-time constraints. Actually, this assumes that the WCET were carefully determined and enough margins were taken to approximate the cost of the RTOS itself, i.e. the cost of the scheduler including the cost of the preemption if it is allowed by the scheduling policy. 5.2 Illustration on an ignition controller In the ignition control system example, the three behaviours: Knock control correction, Over temperature correction, and Warm-up correction are associated to a couple of temporal characteristics (deadline, period), and a WECT that was determined according to the execution platform resources it was allocated to. These associations lead to a system of three periodic tasks: Knock, OverTemp, and Warmup. Their periods initially expressed in °CRK have been translated in milliseconds (from the idealClock) by applying the time constraints between the two clocks. The resulting values are listed in Table 1. With these data, it is possible to perform a scheduling analysis based on a fixed priority scheduling policy. Every tasks is periodic, has a WCET, and a deadline. In addition, preemption is allowed. As the deadline of each tasks is less than its periods, the system of tasks can be scheduled according to the Deadline Monotonic (DM) scheduling algorithm [19], i.e. the task with the smallest deadline has the highest priority, assuming these tasks are independent. If they are not independent a more complex schedulability analysis must be performed, but that does not change anything to the proposed approach. We do not focus on the schedulability analysis itself but on the way it is possible to perform it from the previous models, manually or possibly automatically. In this context, the scheduling analysis using DM algorithm amounts to verify the following sufficient condition. As mentioned before, to be consistent the RTOS running on the considered uniprocessor must use also this algorithm. The system is schedulable if:
WCETi i 1 Deadlinei We chose here the DM fixed priority policy instead of the Earliest Deadline First (EDF) variable priority policy because the scheduler is simpler, and thus its cost is easier to approximate. This approximation is a fundamental hypothesis used in the DM schedulability analysis. Usually the industrial designers take a margin equal up to 30% of the task WCET. With these assumptions our automotive example with the three tasks mentioned above is schedulable if:
WCETKC deadlineKC
WCETOT deadlineOT
WCETWUd deadlineWU 1) (4) Considering the values of Table 1 we can conclude that this system of three tasks is schedulable with the assumption of a MaxRPM equal to 4500. In this case, the left part of the equation is equal to 0.735 < 0.779. On the other hand, if we consider a MaxRPM equal to 6000, the left part of the equation is equal to 0.980 > 0.779 and the system of tasks is not schedulable.
Another constraint to be verified is the timedValueSpecification of the activity diagram (CorrectionAdvanceControl). According to the timedDurationConstraints expressed on Figure 4 the equation 5 must be verified.
t
IDP KC This equation is also valid.
WCET
WCET
OT
WCET WdU t MIxTA (5) 6 Conclusion In order to cope with the complexity of real-time embedded systems, the Model Based Design approach promotes a separation of concerns between the model of the application (functions) and the model of the execution platform.
UML and its profiles are largely used to model both parts. The recent standardization of the UML MARTE profile extends UML with temporal information and physical resources modelling capabilities. Applying this profile to a model based design makes it possible to enrich the application and execution platform models with precise and semantically well founded temporal information. As this information corresponds to explicit model elements endowed with a clear semantic, they can be extracted from the model. Consequently, MARTE models can be used as a starting point for methods and tools intended for schedulability analysis. They take into account temporal information and timing constraints for verifying deadline constraints.
In this paper, we presented the MARTE model elements associated with the time model package of MARTE, and we illustrated their uses on an automotive case study. Four models were presented, the functional model, the time model, the allocation model, and the execution platform model. While temporal information (periods) and constraints (deadlines) are associated with the functional model and are independent from the execution platform model, other timing information (WCET) are dependent of the platform, i.e. the computing resources.
In this approach, there are two notions of time, the time linked to the functional model logical time and the physical time related to both the allocation model and the execution platform model. We showed how to establish the link between logical time and physical time through the allocation model.
From these models we extracted the physical timing information and used them to straightforwardly perform a schedulability analysis. We use an analysis based on the DM algorithm, but others types of analyses are possible, which concludes that the illustrative application, characterized with the temporal characteristics and constraints, is schedulable onto the given execution platform. 1 MARTE OMG Specification. A UML Profile for MARTE, Beta 1.OMG Adopted specification ptc/07-08-04. August 2007. 2 OMG. UML 2.1 Superstructure Specification, April 2006.OMG document number: ptc/200604-02. 3 OMG. UML Profile for Schedulability, Performance, andTime Specification, January 2005. OMG document number: formal/05-01-02 (v1.1). 4 Papyrus: graphical UML2 modelling editor, http://papyrusuml.org 5 Cheddar: http://beru.univ.brest.fr/~singhoff/cheddar 6 SynDEx: http://www-rocq.inria.fr/syndex/ 7 T. Schattkowsky, W. Muller, Model-based design of embedded systems, IEEE symposium on Object-Oriented real-time distributed computing, , pp113-128, Vienna May 2004 8 ITEA project. EAST-ADL: The EAST-EEA Architecture Description Language, June 2004.
ITEA Project Version 1.02.
A Reinterpretation of Patterns to Increase the
Expressive Power of Model-Driven Engineering Matteo Bordin1, Marco Panunzio2, Carlo Santamaria2, and Tullio Vardanega2 1 AdaCore 46 rue d’Amsterdam, 75009 Paris, France
bordin@adacore.com 2 University of Padua, Department of Pure and Applied Mathematics
via Trieste 63, 35121 Padova, Italy {panunzio,tullio.vardanega}@math.unipd.it Abstract. The model-driven engineering (MDE) paradigm wishes to raise the abstraction level of the user design space, while resting on the automated generation of all lower-level artifacts. Under the MDE approach the focus of verification and validation increasingly verges on models. As a consequence, the expressive power availed to the user is often considerably restricted to ensure that the models are amenable to static analysis. Inherent tension thus arises in the very essence of MDE between the restraints to be placed for a better good on the user-level expressive power and the user need and expectation to be able to operate in a modeling space delivered of platform dependences and constraints. In this paper we contend that a new notion of modeling patterns may help resolve the conflict and increase the expressive power in the user space without jeopardizing the integrity and effectiveness of the transformation process. 1
Introduction and related work
Motivation. Model-Driven Engineering [
At present however, the adoption of MDE for the high-integrity application domain is still a challenge. Already in the general case in fact, it may be overly difficult to provide sufficient assurance that all properties attached to the user model and validated at that level of abstraction be correctly propagated throughout model transformations, and preserved upon deployment and execution. This provision demands a level of control over and proof of the production process, which is difficult to attain for the general user.
Matteo Bordin, Marco Panunzio, Carlo Santamaria, and Tullio Vardanega
State of the art. The most prominent efforts in modeling languages for real-time
systems in the industrial landscape to date are AADL and MARTE. AADL [
MARTE [
While both AADL and MARTE provide platform-independent ways of modeling software systems in manners amenable to static analysis, the abstraction level of their modeling space is restrained by constraints arising from the execution semantics intended for the target platform. In fact, in both AADL and MARTE the abstraction level at PIM is almost equivalent to that at PSM. That closeness eases the preservation of model attributes and properties across model transformations, but at the cost of permitting only a shallow distance between PIM and PSM.
The last modeling language we consider is HRT-UML/RCM [
HRT-UML/RCM aims to: (i) provide a design environment in which the user solely
operates in the PIM space, with the only exception of the specification of hardware
configuration and application deployment; and (ii) support an MDE methodology
characterized by principles of correctness by construction [
The HRT-UML/RCM model space does not allow any semantic variation points: the run-time semantics expressed in its models thus always is completely defined. A Reinterpretation of Patterns to Increase the Expressive Power of MDE
In HRT-UML/RCM, the user specification of the PIM is declarative, while the transformation process applied to it corresponds to an implementation designed to be provably correct by construction. The resulting product consequently does not need to be verified a posteriori on a per-system basis, but only requires a single per-platform validation, with important cost savings for the developer.
HRT-UML/RCM has for now elected to produce a single PSM from the PIM. space, though other PSM may in principle be generated, for instance to address dependability, safety and security concerns. In HRT-UML/RCM the PSM is also used as a Schedulability Analysis Model (SAM). The SAM represents the semantics of the system model to the extent of allowing static analysis of the feasibility and sensitivity of its timing behavior. The SAM generated in HRT-UML/RCM is comprised of a set of comparatively simple building blocks, which, through correct-by-construction composition, may arrive at encompassing arbitrarily complex execution semantics.
HRT-UML/RCM seamlessly integrates round-trip support for feasibility and
sensitivity analysis and makes it start and end at the PIM [
Fig. 1. Round-trip timing analysis in HRT-UML/RCM
HRT-UML/RCM also supports automated generation of source code. This leg of the
transformation process starts from the SAM, which eases the provision of constructive
proofs that the system at run time does correspond to what was analyzed and deemed
feasible in the SAM. In the case in instance the complexity of the code generator is
modest since the SAM is very close to the system at run time and the code generation
engine makes extensive use of simple patterns [
A factor that greatly facilitated our attainment of correct-by-construction transformations was the decision to hoist the observance of the RCM constraints from the PSM space up to the PIM. This decision however has the downside that it pushes back onto the user the need to think in implementation terms (so that the RCM restrictions are not violated) in contrast with the promise of delivery from those very concerns.
Matteo Bordin, Marco Panunzio, Carlo Santamaria, and Tullio Vardanega Contribution. The challenge we wish to defy is to raise the user space to a higher level of abstraction (closer to the problem domain and more distant from the constraints of implementation) while guaranteeing preservation and assurance of properties across deeper model transformations. In this paper we discuss the role that MDE patterns may play to this end.
Previous work on the use of patterns in real-time systems [
The remainder of the paper is structured as follows: in section 2 we define what we mean by ”expressive power” in the context of MDE; in section 3 we draw a tentative classification of MDE patterns against the hierarchy of transformations implied in the process; in section 4 we discuss a few example patterns in some details and finally we draw some conclusions. 2
Expressive power in Model-Driven Engineering
We consider the expressive power of a language to relate to its economy of
expressions: the more synthetic the language entities and the denser their semantic contents,
the greater the expressive power. By this definition, the keywords of a programming
language are much more expressive than the words in the instruction set of the
target processor. In the context of programming languages the transformation of a more
expressive program text into a lesser one is taken care of by the compiler. It is a
wellknow observations that the very existence of a compiler for a given target permits to
implement other programming languages equipped with greater expressive power [
The expressive power thus is the capability of expressing, synthetically, high-level concepts with a finite set of language terms with known meaning and with the guarantee that they can be correctly translated into a semantically equivalent set of entities that belong to an underpinning implementation language.
This very principle lies at the heart of the MDE paradigm too. The PIM space may exploit a dictionary of technology- and implementation-independent terms, which model transformation translates to terms that belong to a specific execution platform. Source code is only one of many possible PSM produced by a model transformation of a PIM. In general it is possible to generate a set of PSM each of which serves a different purpose. Each PSM may thus represent the implementation of the PIM at a distinct level of abstraction, or viewpoint, each of which focusing only on the concerns of interest to selected view-specific stakeholder.
The expressive power of PSM is often constrained by the level of formalism required to permit the sound application of domain-specific analysis techniques. For example, constructs that incur non-determinism or unbounded execution behavior may be removed from the PSM language in the prevailing interest of facilitating static analysis.
In general, two opposite approaches can be pursued to increase the expressive power availed to the PIM space: A Reinterpretation of Patterns to Increase the Expressive Power of MDE – granting the maximum possible (in principle, full) freedom of expression to the user and then verifying a-posteriori whether the user model can be successfully turned into a semantically-equivalent and legal PSM; – capturing all of the constraints that propagate up from the PSM and striving to relax all of them for which a transformation pattern may be devised which may be proven correct a-priori and whose eventual overhead may be deemed acceptable to the application.
In the former approach the MDE infrastructure provides the designer with expressive power as large as the user can have. In this case however there is no guarantee that a legal PSM may be obtained from automated transformation of the user model. The verification must be therefore made a posteriori and on a per-model basis.
With the latter approach instead, the infrastructure clearly continues to restraint the expressive power, but for the benefit of a-priori guarantees that any user model in the PIM scope can be automatically transformed into a legal PSM. The metamodel is then the key element to ensure that the user model space is exclusively populated with legal entities, attributes and relations.
In HRT-UML/RCM the PIM modeling space is directly restrained by the
bottomup propagation of semantic constraints from the underlying computational model, cast
onto the RCM metamodel. The RCM originates in language-neutral terms from the
Ravenscar Profile of the Ada programming language [
When the applicable RCM constraints propagate up to directly restrict the user modeling space, the expressive power of the PIM can only be marginally larger than a simple bottom-up projection of the expressive power of the PSM (cf. figure 2.a).
HRT-UML/RCM offers a set of declarative stereotypes to increase the abstraction level in the PIM space. For example, provided services are decorated with attributes that express their intended concurrent behavior and timing properties without the user having to bother with how to implement them. Nonetheless, several restrictions of the RCM (which thus pertain to the PSM) still directly apply to the PIM. For example, the RCM forbids the creation of deferred operations with out parameters (i.e., operations executed by a server-side thread which may return values to the caller) for that would incur synchronous blocking semantics in violation of the Ravenscar restrictions.
We believe that a more advanced use of MDE patterns may help us extend the expressive power of the PIM. We want to attain the maximum possible increase while maintaining the guarantee that all the user models expressible in the PIM space can be represented as (arbitrarily complex and yet correct by construction) compositions of legal PSM entities. A deterministic yet efficient function must exist to transform the
Matteo Bordin, Marco Panunzio, Carlo Santamaria, and Tullio Vardanega constructs that belong in the extended PIM space into a combination (thus, intuitively, a composition pattern) of those primitively present in the PSM (see figure 2.b).
Granted, the additional expressive power can only come at some cost: the larger the distance between the declarative language of the PIM and the implementation language of the PSM, the greater the time and space overhead of the model transformation, of its code products and of and its verification effort. 3
Classification of patterns Let us first introduce a tentative classification of patterns in the MDE landscape. With this classification we maintain that MDE patterns distinguish themselves by the abstraction level at which they are applied. The abstraction level at which any given pattern is considered to belong thus becomes the central element to decide their goodness of fit to serve our objective.
In our current classification, we recognize: A Reinterpretation of Patterns to Increase the Expressive Power of MDE
Determined patterns represent user-perceived solutions to recurrent problems in the
modeling space of the application. The user recognizes a specific problem in the
application requirements and manually augments or adapts the model to host an instantiation
of the desired pattern(s). The design patterns discussed in [
Executive patterns encode traits of the implementation domain of interest. A computational model, a set of constraints on thread activations and suspensions, archetypes to factorize common behaviors, are all example of executive patterns. Executive patterns distinguish themselves because they must necessarily be encoded in the metamodel and fixed once and for all upon its creation. Since they are part of the metamodel, which constrains the legal design space, they determine the PSM expressive power. As the MDE paradigm wishes to lift the abstraction level of the user space away from implementation details, the executive patterns need not be directly visible to the user.
Declarative patterns are themselves solutions to a recurrent problem of the application domain. More specifically, the designer recognizes a known problem in the system specification and uses one of these patterns to solve it. Declared patterns must be semantically understood by the user and recognized as solutions to specific problems in the application space. They however require no implementation from the user, who just need to cause them into existence. It is the process of model transformation in fact that instantiates the required patterns and embeds them in the user model. For this reason declarative patterns must pose no obstacle for the products of model transformation to stay within a legal, correct by construction, design space. The most effective way to achieve this is for declarative patterns to exist in the metamodel and consequently be used as constructive elements of the model transformation logic. Following our definition, declarative patterns augment the expressive power availed to the user, since they result from constructs (e.g.: attributes) that model transformation resolves in a predefined and correct by construction composition of primitive entities of the PSM. Furthermore, the semantics of a declarative pattern is known and well defined and the enforcement of legal conditions for its application can be assured by the MDE infrastructure itself; both these characteristics are instead contemplated in the application of determined patterns.
One of the goals of this categorization is to let the reader appreciate how important those patterns may be to the MDE process and how much they may influence the expressive power availed to the user.
As we have seen, executive patterns basically determine the expressive power available at the PSM level, that is the (low-level) abstraction layer of the entities that populate the system at run time.
Determined patterns live entirely in the user-level design space; they are composed of primitive entities that can legally populate the PIM and therefore have scarce importance in the MDE process, since they do not augment the expressive power.
Matteo Bordin, Marco Panunzio, Carlo Santamaria, and Tullio Vardanega
Declarative patterns instead arguably are the most important category of patterns in the context of an MDE process: they provide the user with a powerful abstraction that is automatically instantiated by model transformations and therefore fit perfectly into the model(s) product of the transformation.
It is then clear that declarative patterns are a crucial instrument for us to increase the expressive power we may avail to the user. Expressed graphically with reference to figure 2, we are increasing the slope of the lines that join the PSM space to the PIM.
One additional benefit of this classification is that makes it clear where the instantiation of each pattern occurs. Figure 3 provides a diagrammatic representation of this element of information: determined patterns clearly populate the application layer, since they are composed of legal entities of the user-level design space; executive patterns map or encode features of the execution environment, whether software (kernel or middleware or both) or hardware; declarative patterns, finally, reside at PIM level, but outside the direct projection of the PSM expressive power and thus require model transformation to come in existence as a correct by construction assembly of legal PSM entities and constructs.
Fig. 3. Patterns in model-driven engineering. Determined and declarative patterns are avaliable in the user modeling space. Determined patterns result from direct projections of the PSM expressive power. Declarative patterns exist beyond the projection of the PSM expressive power and require model transformation to be implemented in terms of legal PSM entities. Executive patterns solely exist in the PSM level.
Let us now determine whether and to what extent the user should be aware of patterns, according to their class of belonging.
Determined patterns are obviously known to the designer, who is the primary and sole actor in their use. Conversely, executive patterns are intentionally hidden to the user. The situation is not that clear instead for declarative patterns. Should the designer be aware that the decoration of some model attributes triggers the activation of a declarative pattern? Additionally, should the designer explicitly require the activation of a pattern or else simply rely on the intelligent support of the framework to recognize the conditions for its activation? Two analogies may help us illustrate the differences between these two approaches. A Reinterpretation of Patterns to Increase the Expressive Power of MDE
One of the classical optimization performed by a compiler is to move the invariant part of a loop outside the loop itself. The average programmer need not be aware that this optimization is performed. Conversely, let’s imagine a programming language that prescribes that remote operations be flagged with a remote keyword; in this case the programmer intentionally determines the generation of stubs, skeletons, and all other elements required to perform a remote invocation. At present we do not have a strong position on the entire class of declarative patterns, and we are inclined to believe that the issue should be evaluated on a case by case (i.e., per pattern) basis.
Pattern catalogue This section briefly discusses examples of patterns from the categorization we have just proposed. The examples we have chosen reflect problems typical of the real-time application domain. We concentrate on declarative and executive patterns, because determined patterns should be well known to the reader.
Partitions and communication filters
While the notions of partition and communication filters are not new to software
engineering, especially in the high-integrity domain (see for example the ARINC-653
standard [
The use of logical and physical partitions permit to attribute software and hardware components to distinct levels of criticality so as to guarantee the required level of isolation in time, space and communication among them.
The notion of partition must be part of the metamodel itself, because the designer must be able to consciously allocate multiple executable entities within given partitions. In that manner, the entities included in a partition inherit the partition criticality and benefit from the partition-level isolation mechanisms. Neither the causing of criticality inheritance nor the modeling of isolation mechanisms, however, are to be explictly performed by the user: they can instead be easily realized by way of model transformation. The notion of partition does thus reflect a declarative pattern.
Communication filters are tightly related to partitions. When a lower-criticality partition establishes a communication link with a higher-criticality partition, the integrity of the exchanged messages should be subject to verification. The execution of the higher-criticality partition may in fact be affected by the computation required by a lower-criticality partition. To only permit allowable communications (operation requests or reports of results), filters are suitably interposed between communicating partitions to perform all of the necessary verification on the permissibility of the communication.
Filters are part of the metamodel. However they are not to be used explicitly by the user, who need not even be aware of their existence, but rather they are put into place by the tail end of the model transformation process. The notion of filter does thus reflect an executive pattern.
Matteo Bordin, Marco Panunzio, Carlo Santamaria, and Tullio Vardanega 10 The purpose of the Callback pattern is to extend the PIM expressive power beyond the projection of the PSM modeling space. The pattern can be categorized as both an executive and declarative pattern. It does not require any specific action from the designer (as thus equates to an executive pattern), but its application has consequences which must be known to the user, as they impact the software architecture and the interpretation of analysis results.
Let us use a simple example to illustrate the Callback pattern, which we base on the classical producer-consumer archetype. Both the Producer and the Consumer have a single method, respectively produce and consume (cf. figure 4). The operation of produce consists in (a) producing an item, (b) passing it to the consumer and (c) adapting its own behavior according to the Consumer’s feedback. The operation of consume consumes the item and returns its feedback via an out parameter, Feedback.
Fig. 4. Callback pattern: class diagram prior to the application of the pattern.
Following the HRT-UML/RCM modeling semantics for components, we declare the concurrent semantics on ports of provided services: the port providing produce is marked ≪cyclic≫, meaning that a dedicated task with a constant periodic release calls produce. The port providing consume is instead marked ≪sporadic≫, meaning that its invocation by a caller causes a sporadic task to be released to actually execute consume (cf. figure 5). Additional non-functional concerns, such as tasks priority and period or minimum inter-arrival time, are addressed by decorating the provided port of each component with specific attributes (which we omit in this discussion).
It is worth noticing at this point that the semantics expressed in this user model is not Ravenscar-compliant. The reason is that operation consume requires a synchronous communication (since its profile includes an out parameter), but the corresponding port is marked ≪sporadic≫, which makes it deferred in HRT-UML/RCM and thus necessarily asynchronous. The semantics intended by the user model is that of a synchronous deferred communication, which is forbidden in RCM. Interestingly however, a simple stage of model validation can notice the problem and trigger appropriate actions to resolve it.
To solve the problem and thus satisfy the user without incurring violations of the RCM restrictions, we first perform an automated model transformation on the class A Reinterpretation of Patterns to Increase the Expressive Power of MDE
Fig. 5. Callback pattern: system model prior to the application of the pattern.
The concurrent semantics declared in the component ports remains the same for those that provide consume and produce. The port providing consume callback is instead marked ≪sporadic≫ so that a dedicated task may ensure a prompt response to the invocation of the callback from consume.
The resulting model is Ravenscar-compliant again as the services provided by the ports marked as ≪sporadic≫ do not include out parameters (cf. figure 7) anymore.
At this point an additional model transformation may generate the SAM and assign the user-specific functional behavior to it. Dedicated tasks are created for produce (cyclic), consume callback (sporadic) and consume (sporadic) and the respective methods are allocated to the fully-legal main operation of the respective tasks. Message queues protected against concurrent access are created for consume and consume callback as the means to implement asynchronous communication between the caller and the sporadic task on the side of the callee. A further shared re
Matteo Bordin, Marco Panunzio, Carlo Santamaria, and Tullio Vardanega source may be automatically generated to safeguard the concurrent access the tasks behind produce and consume callback to application data that the split of the single user-level operation should not duplicate.
Source code is finally generated from the transformed model and from the SAM; no code is instead generated from the original user model. 5
Discussion By the introduction of the executive and declarative pattern categories, we achieve two results which are beyond the reach of classical determined patterns.
Executive patterns, like the Filter pattern, relieve the designer the need to specify complex yet recurrent parts of the software behavior, and rather introduce them directly in the PSM (and, possibly in the source code too).
Declarative patterns instead, serve two distinct purposes. First of all, they reduce the amount of modeling effort required for the designer to express the semantics needed to solve an application-level problem: this is for example the case of the Partition pattern.
Declarative patterns may also help extend the expressive power availed at PIM well beyond the perimeter permissible to the PSM: this is the case of the Callback pattern.
In fact, we see declarative patterns as a most promising pattern category for highintegrity systems in general and real-time systems in particular. They have the potential to release the user-level modeling process from (some of) the restraints that are propagated upwards from the underlying analysis theories, and thus extend the expressive power availed to the user. In practice the restraints that may be lifted are those for which declarative patterns exist which permit model transformations that provably preserve the properties of interest down to the final implementation.
Interestingly enough, declarative and executive patterns are both realized by means of property preserving model transformations and take the form of correct by construction aggregates of primities entities of the metamodel. While those patterns are not primitive entities themselves, they do exist in the metamodel space because it is their very existence under the semantic constraints enforced by the metamodel that asserts their legality. A key implication of this stipulation is that the compositional logic of the model transformations must be defined as an integral element of the metamodel itself. A Reinterpretation of Patterns to Increase the Expressive Power of MDE
What we currently see as the main limitation to the full application of declarative patterns is the impact they may have on the functional (and not only architectural) specification of the system. We have seen a glimpse of this problem in the application of the Callback pattern, which caused us to break a single functional operation into two distinct parts.
To date, mainstream modeling technologies have failed to provide a full and usable representation of action semantics in the metamodel space. This limitation constitutes a technological (though not conceptual) hurdle to our endeavor.
In several, perhaps most cases, declarative patterns cannot be silently applied by the modeling infrastructure as they may considerably increase the distance between the user space and the part of the PSM that is the product of automated model transformation. The larger the distance the more complex to understand the end results of the transformation, in both qualitative and quantitative terms. For example, the application of the Callback pattern not only modifies the functional specification provided by the user, but also impacts the concurrent and synchronization properties of the system by creating an additional task and an additional shared resource. The modeling infrastructure should thus justify all model transformations and provide evidence of traceability between levels of abstraction.
Conclusions The production of formal analysis models is a complex task which requires to verify that (i) the designed model does not evade the boundaries of the semantics permitted by the underlying analysis theories; and (ii) the semantics is preserved at each abstraction level crossed by transformation.
The preferred way to satisfy both requirements is to constraint the modeling space by directly projecting the expressive power of the PSM onto the PIM modeling space (with the side benefit of easing the automated production of the PSM).
We introduced two new categories of patterns specific of the MDE context to add
to the well-know category of determined patterns that stem from [
Executive patterns are expected to deliver the user from the need to specify parts of the architecture and functional behavior of the application by embedding consolidated solutions directly in the PSM (possibly the source code).
Declarative patterns instead extend the expressive power of the PIM by relaxing semantic constraints that hold on the PSM. The implementation of the semantics implied by declarative patterns is naturally realized by automated model transformation.
We discussed three specific instances of patterns in the above categories, which address problems recurrent the real-time systems domain.
The introduction of those new categories of patterns promises to increase the expressive power attainable at user level and an interesting new dimension of automation in the model-driven engineering of real-time systems. The full exploitation of those patterns requires a highly integrated modeling infrastructure, which includes a mod
Matteo Bordin, Marco Panunzio, Carlo Santamaria, and Tullio Vardanega
References