C André
email: andre@unice.fr

F Mallet
email: fmallet@unice.fr

M-A Peraldi-Frati

Aoste

Multiform Time in UML for Real-time Embedded Applications

Each domain has its own interpretation of time. We propose to extend UML, which is more and more used in the domain of real-time embedded applications, with a concept of time inherited from reactive system modeling : multiform time.

After a brief review of some UML profiles, we present our extensions and we illustrate-on an example from the automotive industry-how to represent and to constraint behaviors depending on multiform time. We advocate that this model of time offers wider possibilities than restricting models only to the physical time.

Introduction

Modeling and analysis of real-time embedded (RTE) application passes by the expression of time constraints. Even though in the common life we are used to express time using units of the international system, we are not bound to do the same for RTE applications. Actually, each domain may have its own interpretation and modeling of time. F. Schreiber [START_REF] Schreiber | Is Time a Real Time? -An Overview of Time Ontology in Informatics[END_REF] has described several aspects of time and defines ontologies for time in different domains of computers and their applications. Each domain defines its own language and there is a strong demand for a standard description of systems in general and time properties in particular. In this context, visual modeling languages like UML and SysML are good candidates.

RTE systems have specific requirements. Real-time systems, on the one hand, require constructs to model timedependent events and behaviors, as well as constraints on event occurrences and execution durations. On the other hand, embedded systems are subject to additional constraints due to their limited resource availability. UML 2.0 offers constructs to represent events and behaviors, and 1 http://dx.doi.org/10.1109/RTCSA.2007.51 to express constraints. However, given that the default operational semantics of the UML is inherently untimed, and rightfully so since there is no Time information in the ground metamodel, the same model can be interpreted differently depending on whether it is considered from the UML causality model or the intended timed analysis viewpoint.

Our notion of time covers both physical and logical times. Multiform time, originating from reactive system modeling, is our time model. Most of the ideas presented here have been proposed to the OMG for inclusion in the forthcoming UML profile for Modeling and Analysis of Real-Time Embedded (Marte [START_REF] Omg | UML profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE)[END_REF]) systems. The extensions we propose to support multiform time modeling are applied to an automotive control application.

We start with a survey of some existing UML profiles. We continue by introducing the logical time and the extension proposed in Marte to take account of the multiform time. Section 4 presents the automotive application used in section 4.3 to illustrate the usage of our UML extensions. We insist on time constraints that can be used by tools to validate time properties.

Time modeling in UML and some of its extensions

UML

In UML [START_REF] Omg | UML 2.1 Superstructure Specification[END_REF] Time is seldom part of the behavioral modeling, which is essentially untimed (by default, events are handled in the same order as they arrive in event handlers). UML describes two kinds of behaviors: the intraobject behavior-the behavior occurring within structural entities-and the inter-object behavior, which deals with how structural entities communicate with each other [START_REF] Selic | On the semantic foundations of standard uml 2.0[END_REF]. The CommonBehaviors package defines the relationship between structure and behavior and the general properties of the behavior concept. A subpackage called SimpleTime adds metaclasses to represent time and duration, as well as actions to observe the passing of time. This is a very simple c 2007 IEEE time model, not taking account of problems induced by distribution or by clock imperfections. In particular the UML causality model, which prescribes the dynamic evaluation mechanisms, does never refer to time (stamps). Instead, the UML specification document explicitly states that "It is assumed that applications for which such characteristics are relevant will use a more sophisticated model of time provided by an appropriate profile". Our contribution can be seen as providing the means for building such sophisticated time models.

SPT

The UML Profile for Schedulability, Performance, and Time (SPT) [START_REF] Omg | UML Profile for Schedulability, Performance, and Time Specification[END_REF] aimed at filling the lacks of UML 1.4 in some key areas that are of particular concern to real-time system designers and developers. SPT introduces a quantifiable notion of time and resources. It annotates model elements with quantitative information related to time, information used for timeliness, performance, and schedulability analyses.

SPT only considers metric time, which makes implicit reference to physical time. It provides time-related concepts: concepts of instant and duration, concepts for modeling events in time and time-related stimuli. SPT also addresses modeling of timing mechanisms (clocks, timers), and timing services. But "time" here is only introduced through dedicated stereotype annotations that are not interpreted and given meaning as part of UML semantics. Instead, their purpose is to be understood by external analysis tools to perform schedulability or performance evaluation and after automatic translation from the UML model into such tool input format.

SPT, which relies on UML 1.4, had to be aligned with UML 2.1. This is one of the objectives of the Marte profile.

SysML

SysML (Systems Modeling Language) [START_REF] Omg | Systems Modeling Language (SysML) Specification[END_REF] is a generalpurpose modeling language for systems engineering applications. Though SysML offers no specific support for Time, it extends UML in several ways. Our time model has taken up two of these extensions: value property with units, and constraint block. A SysML value property defines a value with units, dimensions, and probability distribution. A SysML constraint block contains equations expressing constraints between value properties. The usages of the constraints in an analysis context are represented in a parametric diagram (kind of diagram new to UML).

Non OMG profiles

Several UML profiles, which are not responses to an OMG RFP, are dealing with time. None of them supports multiform time.

EAST-EEA, an ITEA project on Embedded Electronic Architecture [START_REF] Project | EAST-ADL: The EAST-EEA Architecture Description Language[END_REF], provides a development process and automotive-specific constructs for the design of embedded electronic applications. Temporal aspects in EAST are handled by requirement entities. In theory, concepts of Triggers, Period, Events, End to End Delay, physical Unit, Timing restriction, can be applied to any behavioral elements. In practice, some of these concepts, such as the event triggering, make the timing analysis very complex. In the EAST-ADL (Architecture Description Language) document, it is recommended to use event triggering carrefully or even to avoid it.

The temporal semantics of AADL [START_REF] Standards | SAE Architecture Analysis and Design Language[END_REF] concepts is defined using "hybrid automata". These automata are hierarchical finite state machines with real-valued variables that denote the time. Temporal constraints, expressed as state invariants and guards over transitions, define when the discrete transitions occur. Concurrent executions are modeled using threads managed by a scheduler. The dispatch protocol (periodic, aperiodic, sporadic and background) determines when an active thread executes its computation. AADL supports multiform time models. However, it lacks model elements to describe the application itself, independently of the resources. UML activities allow for a description of the application, actions executed sequentially or concurrently, without knowing, at first, whether actions are executed by a periodic thread or a subprogram. This important information is brought by an orthogonal process: the allocation. After several analysis iterations, the threads are eventually deployed to the execution platform.

The UML profile Omega-RT [START_REF] Graf | A real-time profile for UML[END_REF] focuses on analysis and verification of time and scheduling related properties. It is a refinement of the SPT profile. The profile is based on a specific concept of event making it easy to express duration constraints between occurrences of events. The concept of observer, which is a stereotype of state machine, is a convenient way for expressing complex time constraints. Note that the Omega Event is different from the UML Event, which poses a compliance issue. TURTLE-P [START_REF] Apvrille | TURTLE-P: a uml profile for the formal validation of critical and distributed systems[END_REF] is a UML profile for the formal validation of critical and distributed systems. This profile introduces temporal operators and composition (parallel, sequence, synchronization, and preemption). It deals with temporal non determinism, usual in distributed systems. Properties of a TURTLE-P model can be evaluated and/or validated thanks to the formal semantics given in RT-LOTOS.

Multiform time and Marte

A first form of time is the one used in physical laws, and especially in mechanics. In computer science this time is often referred to as "physical time", but its nature is above all mathematical.

In digital systems, this ideal time is approximated by circuits, called clocks, generating well defined "periodical" signals. This leads to a discrete model of time. Unfortunately, a digital system often needs several clocks. This raises the problem of clock synchronization [START_REF] Messerschmitt | Synchronization in digital system design[END_REF]. Distributed systems, because of their spatial extension, experience the same problem to agree on a unique time reading. To address this issue, L. Lamport [START_REF] Lamport | Time, clocks, and the ordering of events in a distributed system[END_REF] has introduced the concept of logical clock. With logical clocks, partial ordering of events can be obtained without recourse to any physical "real" time. Improvements in logical clocks permit to characterize the causal relationship among events [START_REF] Schwarz | Detecting causal relationships in distributed computations: In search of the holy grail[END_REF]. For performance evaluation or hard real-time property verification, a time model restricted to partial ordering of events is not enough. Synchronization with physical time becomes necessary (see the Enhanced View of Time Specification [START_REF] Omg | Enhanced View of Time Specification[END_REF] for proposed standard and service definitions).

The synchronous languages [START_REF] Benveniste | The synchronous approach to reactive and real-time systems[END_REF][START_REF] Benveniste | The synchronous languages 12 years later[END_REF], used in reactive system programming, also make use of logical time. In synchronous programming, (physical) time passing is represented by event occurrences; for instance a signal generated by an external device. However, these events do not have any specific status that distinguishes them from other events. Hence, a synchronous program may have statements such as "a task must complete before 10 ms", and "a car must stop within 50 m". Both statements express a deadline: "10 ms" for the former, and "50 m" for the latter. This is known as Multiform Time.

Marte is a response to the OMG RFP to provide a UML profile for real-time and embedded systems [START_REF] Omg | UML profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE)[END_REF]. Marte is a successor of SPT, aligned on UML 2, and with a wider scope. Marte introduces a number of new concepts, including time concepts, which are central to this paper. The main Marte extensions of UML for time-related concepts are informally described below. This presentation focuses on the concepts (domain view) rather than the formal UML specification of the profile (UML view).

The underlying model of time is a set of time bases. A time base is an ordered set of instants. Instants from different time bases can be bound by relationships (coincidence or precedence), so that time bases are not fully independent and instants are partially ordered. This partial ordering of instants characterizes the time structure of the application. This model of time is sufficient to check the logical correctness of the application. Quantitative information can be added to this structure when quantitative analyses become necessary. Note that a specification of a temporal behavior may refer to points of time (instants) or to segments of time (durations). In the Marte metamodel of time, Instant and Duration are two distinct concepts, specialization of the abstract concept of Time.

The users of Marte have access to the time structure through clocks. Here, clocks are not physical devices; they are model elements representing a general concept of time.

While in SPT, clocks were implicitly bound to the physical time, in Marte, a clock can be bound to any recurrent event.

Thus, Marte distinguishes two kinds of clocks: the chronometric clocks, which make reference to physical time, and the logical clocks, which focus on the ordering of instants, possibly ignoring the physical duration between instants.

Some classes are sterotyped by the stereotype ClockType, they define the type of a clock. Such a class specifies the nature (dense or discrete) and the kind (chronometric or logical) of the represented time, a set of clock properties (e.g., resolution, maximal value, . . . ) a set of accepted time units. For the chronometric clock types, time units are the usual time units: the second (s) and its derived units. Most logical clock types use a generic time unit called tick. In some cases, they may use more specific units: a processor cycle, for instance, or even units for physical quantities, like in the illustrative example of this paper, where time is measured in angular degree ( • ). A Clock (i.e., an instance of a Clock-Type) is characterized by its unit and the values (real numbers) given to its optional properties: resolution, maximal-Value, offset. resolution gives the granularity of the clock; maximalValue is the value at which the clock roll over; offset specifies the origin instant. The resolution, the maximal-Value and the offset are given with the unit of the clock. A predefined Clock is provided in the TimeLibrary of Marte: idealClk. This hypothetical clock reads the dense "physical time". It is used as a reference clock for the (imperfect) chronometric clocks defined by the users of the profile. A ClockConstraint sets dependencies up amongst clocks.

In Marte time model, time-related concepts (e.g., event occurrences and behavior executions) make explicit reference to one or several clocks, through the property on, on identifies the clock and then the unit used. In UML, an Event describes a set of possible occurrences; an occurrence may potentially trigger effects in the system. A TimeEvent is an Event that defines a point in time (instant) when the event occurs. The specification can be either absolute or relative to some other instant. A TimedEvent is a TimeEvent, where the instant specification explicitly refers to a clock. Note, that in the general case it is not possible to compare two events that refer to two different clocks. The comparison is only possible when specific constraints on the clocks (ClockConstraint) or the events (InstantConstraint) are given. A UML Behavior describes a set of possible executions; an execution is the performance of an algorithm according to a set of rules. Marte associates a duration, an instant of start, an instant of termination with an execution, these times being read on a clock. A TimedProcessing is a Behavior or an Action with explicit references to clocks.

Application to an Automotive system

This section presents an automotive application: an ignition control and the knock correction in the case of a 4stroke engine.

Spark-ignition engine

In a 4-stroke engine, a cycle is characterized by four phases: Intake, Compression, Combustion and Exhaust. These phases are driven by the camshaft, the positions of which are measured in angle degree ( • ).

Since the spark plug needs a delay to produce a flame front in the combustion chamber, the electric spark must be generated before the theoretical ignition point (ITDC: Ignition Top Dead Center) and after the Maximal Ignition Advance Angle (MIAA).

During the compression phase, at the Ignition Decision Point (IDP), an electronic control system determines the best angular position to generate an electric spark for igniting the compressed air-fuel mixture. Starting from the Basic Ignition Advance Angle (between MIAA and ITDC), which is a function of the actual engine speed and the air/fuel rate, a correction is applied to determine the Actual Ignition Advance Angle (AIAA). These corrections depend on additional parameters. The angle from ITDC to AIAA is called the advance.

The example of the Knock

The knock is a physical phenomenon generated by an auto ignition during the combustion phase and leading to a lost of efficiency of the engine, a consumption increase, and may cause irreversible damage to the cylinder. The knock control system detects and corrects this phenomenon. It consists of one or several noise sensors, and a controller, which performs the acquisition and computes the correction. Acquisition of the noise sensor signals is carried out during an observation window (KAW-Knock Acquisition Window). The starting point (KAWS-KAW Start) and the duration (KAWD-KAW Duration) of the window may vary. They depend on the knock intensity (KI) measured during the previous combustion phase. The knock controller is an adaptive system. A digital filtering is applied to the signal samples to deduce the knock intensity. This value is then used to adjust the advance (advance correction). More details about spark ignition engine management and knock control system can be found in an automotive handbook [START_REF] Bosch | Bosch Automotive handbook[END_REF].

Modeling behavior with logical clocks

The ignition engine management is a typical example of real-time application gaining from a multiform time model-ing.

In a UML state machine, a label on a transition specifies a trigger that must reference an event. Labels like "after d" or "at i" implicitly defines a TimeEvent. The former specifies a relative instant, the later an absolute instant; these instants implicitly reference physical time. In Marte, this convenient notation is extended to multiform time events, by applying the TimedEvent stereotype. In a 4-stroke engine, the succession of the phases is triggered by events associated with angular positions of the camshaft, not with physical time instants. In a multiform time approach, angular positions of the camshaft are considered as (logical) instants read on a logical clock: camClk. This clock represents a discrete logical time, its unit is defined as • CAM (degree cam), its resolution is 0.5 (for instance), its offset is 0, and its maximalValue is 360. All the values are implicitly given in • CAM , the unit of the clock.

The events that trigger the transitions in the state machine shown in Figure 1 are stereotyped by TimedEvent, and the tag value on set to camClk. For instance, we call IC (Intake closes) the event associated with the transition from Intake to Compression; it is a TimedEvent occurring 90 • CAM after entering state Intake. Note that, the whole state machine, which is a UML Behavior, has been stereotyped by TimedProcessing. The events involved in the state machine are, by default, bound to the same clock (i.e., camClk). This state machine is a simplified specification of the behavior. In actual engine, the Intake and the Exhaust phases are overlapping. This overlapping can be shown using UML interactions. Of course, in Marte interaction diagrams are extended to multiform time.

In Figure 1, we used the camClk. For some other aspects, it is easier to use another logical clock: crkClk (crankshaft clock), with • CRK (degree crank) for unit. This clock is bound to the rotation of the crankshaft. Since a full 4-stroke cycle needs two revolutions of the crankshaft, the maximal value of this clock is 720 • CRK. Its resolution is assumed to be 0.5 (for instance).

The camshaft and the crankshaft are mechanically bound: the latter runs twice as fast as the former. Conse-quently, the two clocks camClk and crkClk are tighly dependent; this dependency is expressed by a ClockConstraint (Eq. 1).

camClk = crkClk filteredBy (1.0) (1)
This equation states that camClk is a subclock of crkClk, with instants of camClk being coincident with every second instants of crkClk. The coincident events are represented by a filtering operation according to an infinite periodic binary word 101010..., the shortcut of which is (1.0). Figure 2 presents the result of the application of Eq.1. This is a total order amongst instants of the same clock.

Figure 2. Clock constraint between camClk and crkClk.

On Figure 1, each phase is separated from the next one. On an actual engine, there is an overlap between phases. For example, the Compression phase starts before the actual end of the Intake phase. The start of the Compression phase is called FBDC (First Bottom Dead Center). The end of the Intake phase is IC. Using a clock constraint we can express the overlapping (Eq. 2).

(t F BDC + 40 ≤ t IC ≤ t F BDC + 60) on crkClk (2)
In that case, the constant values, 40 and 60, are expressed according to the • CRK clock unit. Using two different logical clocks provides more flexibility since it allows for using exact values found in handbooks and specifications. Of course, using several units in the same specification is possible only if there is a strong support from tools. Our profile avoids the burden of building a specific tool since graphical support and constraint editing are to be provided by UML tools that implement the Marte Profile.

Mixing logical and chronometric clocks

In real-time applications, the behavior executions are generally temporally constrained. A deadline imposed on the termination of an execution is a usual constraint that can be specified either by a duration (maximal execution time) or by an instant (occurrence of a timeout event). Here again, Marte provides facilities to express such constraints on multiform time models.

The ignition control decomposes in three actions. First we get the basic ignition advance angle (BIAA) by a table lookup with two input parameters: the current air/fuel ratio and the current engine speed (i.e., the rotational speed of the crankshaft). The BIAA data is then used by a Corrections action that uses, among other factors, the knock intensity (KI). This action yields two results: the corrected ignition advance angle (CIAA) and information on the knock acquisition window, described below. The last action generates the actual advance (ADV). This sequence of actions is triggered at the ignition decision point (IDP). The IDP event occurs at a fixed angular position, therefore at a fixed instant on the crkClk. The new advance value must be available, under any circumstances, before another angular event (MIAA) that corresponds to the worst case (i.e., maximal engine speed and maximal allowed advance). Thus, the duration of the execution of the main ignition control activity must be less than (M IAA -IDP ) • CRK.

The main ignition control (MICtrl) activity is just a part of the ignition control (ICtrl) activity (not represented here). The various corrections can be computed concurrently. For simplicity, we consider only the knock correction. The knock sensor is a vibration sensor that is sampled at 100 kHz (a classical frequency for vibration analysis). The use of a frequency unit makes implicit reference to physical time. In this application, as in many other control applications, logical clocks and chronometric clocks have to live together.

We can use another activity diagram (not shown here) to represent the behavior of the knock control (KCtrl). The behavior is triggered by the occurrence of the ITDC event (i.e., when the crankshaft is at its top dead center at the end of the compression phase). This event occurs at a fixed instant (360 • CRK) on crkClk. The WaitWS action waits for the delay KAWS (Knock Acquisition Window Start, part of the KAW data). The knock signal acquisition action (KSA) is then carried out. Two events, KWB and KWE, denote the start and the end of this action. The acquisition fills in a buffer that is then read by the action Filtering. The knock intensity (KI) is the result of the filtering.

The acquisition terminates either when the buffer is full or when the knock acquisition window duration (KAWD, part of the KAW data) has elapsed. The first occurring event causes the effective termination. This is a multiform time constraint. The latter condition is measured in • CRK while the former is bound to physical time through the imposed sampling period. The constraint is specified by: t KW E -t KW B = min ( sampleNb * Tsampling on ide-alClk, KAWD on crkClk), where sampleNb is the maximal number of samples in the buffer, Tsampling is the period of sampling (10µs since the sampling frequency is 100 kHz), KAWD is the knock acquisition window duration, a value given in • CRK and dynamically computed by the Corrections action of the main control system. The simplest way to make computation on these kinds of constraints is to relate them to actual chronometric clocks, for example to the idealClk defined in the Marte library. Such a constraint would depend on the engine speed. If we consider an engine with the maximal engine speed of 4500 rpm (revolutions per minute). A revolution is 360 • CRK; The maximal engine speed is 27000 • CRK/s, so that 1 • CRK ≥ 37 µs.

When considering an engine with four cylinders instead of a single cylinder, constraints become stronger. The ignition control activity (ICtrl), and hence the activity MICtrl that is part of it, must be executed for each cylinder. However, each cylinder has its own clock: crkClk1, crkClk2, crk-Clk3 and crkClk4. Making clocks a first class citizen of Marte allows for using clocks as parameters of activities. The commonalities amongst these clocks are defined by the ClockType AngleClock; each cylinder clock becoming an instance of AngleClock. The offset of each clock is different and determined by the engine firing sequence (order of combustion). For an engine whose firing sequence is 1,3,4,2, the offsets of the clocks are respectively 0,180,540 and 360 for crkClk1, crkClk2, crkClk3 and crkClk4.

The dependencies are not limited to a simple sequencing of activities, we must also take into account hardware resources involved. That is why Marte has also extended composite structure diagrams with multiform time.

Conclusion

We believe that multiform time, introduced by reactive languages, is of first importance to specify constraints in real time embedded systems. Additionally, UML is more and more present in the industry to bridge the gap between the domain experts, the customers and the developers. This paper introduced some efforts made in the context of the forthcoming UML Profile called Marte to take account of the multiform time in UML diagrams. The goal is to use UML visual editors to capture specifications and time constraints. Using logical clocks keeps the specification as close as possible from the domain expert handbooks. Then, time analysis tools should be able to extract Marte annotations to validate some constraints. On a simplify example, borrowed from the automotive domain, we have shown that with few time constraints we can capture enough information to perform multiform-time analysis. Some validations have been performed in [START_REF] André | A multiform time approach to real-time system modeling: application to[END_REF], these validations concern performance and cost requirements (processor speed, number of buffers and their size), as well as variability requirements (number of cylinders).

This study has been partially supported by the RNTL Memvatex project (www.memvatex.org), which provides the application case study.

Figure 1 .

 1 Figure 1. State machine of a 4-stroke engine cycle.


Professor Denis Musso

T M C Asser Instituut

Continuing to build the European Model of Sport

Introduction

The recent European Court of Justice's Kolpak ruling1 gives us another opportunity to focus on the combination of public law and sporting rules in the sport law matters, particularly regarding professional sport. Each sporting situation is positioned in the spotlight of different levels of legality. Three geographical zones may be distinguished: the regional level as, for example, in Italy or Spain where Regional Sport Acts exist; the central national level; and the European level where Community law applies. What has changed since 1995 and the famous Bosman ruling2 ? Although Deliege and Lethonen, have confirmed the applicability of the freedom of movement of workers in sport, they also have allowed more flexibility in the application of Community law to sport. Nevertheless, with respect to fair competition, have the sport federations, in the light of their monopoly, secured their role in the future of professional sport? As professional sport includes not only sporting and economic, but also cultural and historical dimensions, a special treatment is needed.

Basics

Some basics have to be stressed before considering the future. With reference to the pertinent document that was drafted by the European Commission in 19983 , one could say that if there is no real model of sport in Europe, there still are enough shared values and forms of organisation to make up a genuine model, which is based on some established principles. It is time now to define them. Different aspects may be observed.

System of Sports Organisations

Some aspects concern the system of sports organisations. The Nice Declaration, which was adopted in December 2000, stressed the need to preserve and promote the social functions of sport and the key role of sports federations to ensure the necessary solidarity between the various levels at which sport is practiced: from recreational to top-level sport. In Europe, sports federations have a historical legitimacy to run the professional sport system. The pyramid form of sports organisation and the promotion/relegation system are a common feature and a guarantee of the sporting, which is superior to the economic one.

If public actors-like States and European Union-recognise the social, educational and identity-building roles of sport, it means that sport is not an ordinary article. Sport must have ethical meanings, i.e., encouraging team spirit, solidarity and fair-play, helping to fight against doping 4 , racism and xenophobia and protecting young people who are taking part in top-level competitions.

Legal nature of Sports Federation

Another issue is the legal nature of the sports federations. Originally, the federations are nonprofit organisations, run by elected volunteers. Board members are not the owners of the federation, they are militants pursuing the goal of the federation and implementing its actions. This is the main difference in comparison with the management of private commercial companies 5 .

Decision-making process

The third issue concerns the decision-making process. The typical method used in the sports federations is the one-sided decision. Today, it is an outdated and inadequate instrument for running professional sport. In professional sport management, the various actors must be involved in the decision-making process; in particular, the clubs and the players. This is the essence of the Social Dialogue which was launched by the European Commission 6 . The Social Dialogue is a consultation mechanism for employers and employees, "both sides of the industry", at the central European level and at the level of industrial sectors. The Social Dialogue is incorporated in articles 138 and 139 of the EC Treaty. However in the E.U., professional sport is not an industry. It is under control of the sports federations; and a key success factor for the Social Dialogue in professional sport will be how to imagine and create an original way to integrate sports federations in the process. With regard to the various aspects, it is important to have a better knowledge of the characteristics and initiatives undertaken in different European countries.

Matters to be considered

Foundations

For example, the United Kingdom tells us that sport essentially is an autonomous movement, based on private initiative, where superior goals are not of an economic nature. Therefore, both State intervention and economic power should be limited. In Italy, it is interesting to see how the professional sector is construed 7 . If the federation decides to set up a professional sector, the employment contract of each athlete has to be concluded under a collective bargaining agreement, which is signed every three years, by the representatives of employers and employees, under the aegis of the federation.

Inspiration can be drawn also from France. Some particular points, which are included in the present Sport Act 8 , may serve not as a model but as food for thought. 4 The US professional leagues remained apart from the World Anti-Doping Code, which was accepted at the World Conference on Doping in Sport, Copenhagen, March 2003. 5 See the property rights theory; for instance: Alchan A.A. (1969), "Corporate Management and Property Rights", in H.Manne (ed), Economic policy and the regulation of corporate securities, American Economic Institute, Washington. 6 Conference on the Social Dialogue in professional football, Brussels, 3 April 2003. 7 Legge n° 91 del 23 marzo 1981, sullo lo sport professionistico 8 Loi n°84-610 du 16 juillet 1984 relative à l'organisation et à la promotion des activités physiques et sportives. In 1999 the Act was amended.

Relationship between Sports Federations and the State:

The French model of sport is based on a special relationship between the State and the federations. Since 1940, the State delegates the organisation of all sporting competitions to the federations and only one federation is authorised for each specific sport 9 . This monopoly also allows them to organise and control the professional sports sector. If an organiser , who is not a member of the federation, invites athletes and makes competition prize money available, he has to obtain federal agreement beforehand 10 . Therefore, in France, the federation is in a strong position to organise and/or control professional sport, but, at the same time, to a certain degree, being dependant on the State. For example, when the private company "Société du Tour de France" wants to organise the "Tour", it needs the agreement of the French Cycling Federation. The authorised federation has to respect, as in public service, principles of equality and legality. By way of compensation, the federations are state-subsidized.

Relationship between Sports Federations and the Economic Sector

The second aspect concerns the power of the clubs and leagues. The main aim in France is to limit their powers and bring them under the control of the federations. Professional clubs now have to adopt the statutes of commercial companies but with various obligations 11 . For example, they cannot be involved in the stock-exchange and, until the 1999 Act; they were not allowed to share profits. They were "non-profit companies". Today, only one kind of legal entity allows the profit to be shared 12 . Professional clubs can be grouped in a league. However the league has to be under the control of the federation. Leagues can have an autonomous legal personality only through a non profit organisation 13 .

Property Rights partition

The confrontation between commercial companies and non-profit organisations may be unbalanced. Therefore, the Act gives the federations the exclusive right to commercialise competitions 14 . It is up to them to share TV rights income, for instance between the different actors, i.e., themselves, league and clubs. This system is based on a centralised negotiation of TV rights by the league on behalf of the federation. The brand and logo of the clubs (having the status of non-profit organisations according to French law), can be sold only through establishing a commercial company for professional sporting activities.

Collective agreement

Albeit late, the French sports organisations are now involved in negotiations to prepare and adopt a collective agreement for the whole sports activities branch. It will include a chapter on professional sport which is currently being discussed. The lack of an Act-like the one in Italy, where the federations are obliged by law to sign the agreement-undermines the position of 9 Art. 17 ibid. 10 Art.18 ibid. 11 Art.11 ibid. 12 Société anonyme sportive professionnelle 13 Art.17.II ibid. 14 Art.18-1 ibid.

the federation in the France. The clubs organised themselves in a specific structure named "Conseil Social du Mouvement Sportif" (COSMOS 15 ) to be involved and be active in the negotiating process. On the part of the players, acommon organisation-named "Federation Nationale des Associations et Syndicats de Sportifs (FNASS 16 ) -was set up.

Conclusion

In conclusion, these brief illustrations remind us that the future of the professional sports system has to be considered also taking history into account, in order to preserve the aim oh the Olympic and sporting movement. Today, the genuine European model of professional sport is living on borrowed time. Its future structure in the European Union has still to be built, despite some progress having been made. A new impulse can be given by the European Convention. Article I-16 of the draft proposal provides that the Union may take supporting, coordinating or complementary actions, in particular, education, vocational training, youth and sport. For the first time, the word "sport" is included in the basic legal document of the Union. Despite possible threats, this will provide a first opportunity for continuing to build the European model of sport.

15 www.cosmos.asso.fr 16 Contact: UNFP, 32 rue Feydeau, 75002 Paris, phone: + 33 1 40 39 91 07; fax: + 33 1 42 36 22 21

Case C-438/00, 8 May (2003).

Case C-415/93, (1995) ECR I-4921

"The development and prospects for Community action in the field of sport", 29 September 1998.


Charles André
email: andre@unice.fr

Frédéric Mallet
email: fmallet@unice.fr

Marie-Agnès Peraldi-Frati

A multiform time approach to real-time system modeling Application to an automotive system

Keywords: Embedded systems, Multiform time, High level modeling, UML profile, Timing analysis, automotive application

HAL is

I. INTRODUCTION

The complexity of real-time embedded (RTE) applications is ever increasing, while their time-to-market is getting shorter and shorter. The model driven engineering (MDE) approach has been proposed to solve the challenging issue of the design of RTE applications. There is a strong demand for executable models that cover all the range from specification to implementation, supporting analysis and validation. In this context, visual modeling languages like UML and SysML are good candidates. RTE systems have specific demands. Real-time systems, on the one hand, require constructs to model time-dependent events and behaviors, as well as constraints on event occurrences and execution durations. On the other hand, embedded systems are subject to additional constraints due to limited resource availability. UML 2.0 offers constructs to represent events and behaviors, and to express constraints. However, the UML model of time has purposely been kept simple; UML delegates to appropriate profiles the management of complex time mechanisms. Some profiles attempt to provide such mechanisms, but time-related concepts are often expressed as simple annotations. In our approach, time is part of the behavior, not a mere annotation. Moreover, our notion of time covers both physical and logical times. Multiform time, originating from reactive system modeling, is our time model. This paper presents our UML-based approach to RTE system modeling and analysis. The time-related concepts and the behavioral diagrams of UML are extended to support multiform time modeling. Our enriched UML (part of the MARTE profile) is applied for modeling the behavior of an automotive control application. Examples of timing analysis, which exploit information contained in the UML model, are then given.

The paper is organized as follows: the next section is a survey of time modeling in UML and some of its profiles. We pay a special attention to the forthcoming MARTE profile we have contributed to. Section III presents an automotive application used in the following sections to illustrate our modeling extensions. Section IV contains the main contributions: multiform time modeling, and the extensions of the UML concepts of event, behavior and constraints to multiform time. Section V explains how time information, included in the UML model elements, can be used for timing analysis.

II. TIME IN SYTEMS MODELING

A. Time modeling in Computer Science and Engineering

Time is a major concern in Computer Science and Engineering. However, each domain may have its own interpretation and modeling of time. F. Schreiber [START_REF] Schreiber | Is Time a Real Time? An Overview of Time Ontology in Informatics[END_REF] has described several aspects of time and defines ontologies for time in different domains of computers and their applications.

A first form of time is the one used in physical laws, and especially in mechanics. In computer science this time is often referred to as "physical time", but its nature is above all mathematical.

In digital systems, this ideal time is approximated by circuits, called clocks, generating well defined "periodical" signals. This leads to a discrete model of time. Unfortunately, a digital system often needs several clocks. This raises the problem of clock synchronization [START_REF] Messerschmitt | Synchronization in Digital System Design[END_REF]. Distributed systems, because of their spatial extension, experience the same problem to agree on a unique time reading. To address this issue, L. Lamport [START_REF] Lamport | Time, Clocks, and the Ordering of Events in a Distributed System[END_REF] has introduced the concept of logical clock. With logical clocks, partial ordering of events can be obtained without recourse to any physical "real" time.

 2007 IEEE

Improvements in logical clocks permit to characterize the causal relationship among events [START_REF] Schwarz | Detecting Causal Relationships in Distributed Computations-in Search of the Holy Grail[END_REF]. For performance evaluation or hard real-time property verification, a time model restricted to partial ordering of events is not enough. Synchronization with physical time becomes necessary (see the Enhanced View of Time Specification [START_REF] Omg | Enhanced View of Time Specification, version 1[END_REF] for proposed standard and service definitions).

The synchronous languages [START_REF] Benveniste | The Synchronous Approach to Reactive and Real-Time Systems[END_REF] [START_REF] Benveniste | The Synchronous Languages 12 Years Later[END_REF], used in reactive system programming, also make use of logical time. In synchronous programming, (physical) time passing is represented by event occurrences; for instance a signal generated by an external device. However, these events do not have any specific status that distinguishes them from other events. Hence, a synchronous program may have statements such as "a task must complete before 10 ms", and "a car must stop within 50 m". Both statements express a deadline: "10 ms" for the former, and "50 m" for the latter. This is known as Multiform Time.

The next section surveys the time modeling capabilities of UML and some of its extensions.

B. Time modeling in UML and its extensions 1) UML

UML [START_REF] Omg | Unified Modeling Language: Superstructure, version 2[END_REF] can describe two kinds of behaviors: the intraobject behavior-the behavior occurring within structural entities-and the inter-object behavior, which deals with how structural entities communicate with each other [START_REF] Selic | On the Semantic Foundations of Standard UML 2.0[END_REF]. The CommonBehaviors package defines the relationship between structure and behavior and the general properties of the behavior concept. A subpackage called SimpleTime adds metaclasses to represent time and duration, as well as actions to observe the passing of time. This is a very simple time model, not taking account of problems induced by distribution or by clock imperfections. The UML specification explicitly states that "It is assumed that applications for which such characteristics are relevant will use a more sophisticated model of time provided by an appropriate profile".

2) SPT

The UML Profile for Schedulability, Performance, and Time (SPT) [START_REF] Omg | UML Profile for Schedulability, Performance, and Time Specification, version 1.1[END_REF] aimed at filling the lacks of UML 1.4 in some key areas that are of particular concern to real-time system designers and developers. The "lack of a quantifiable notion of time and resources" was considered as an impediment to the broader use of UML in the real-time and embedded domain. The modeling of the multiform time is addressed neither by SPT nor by UML2.

3) SysML

SysML (Systems Modeling Language) [START_REF]OMG, Systems Modeling Language (SysML) Specification[END_REF] is a generalpurpose modeling language for systems engineering applications. Though SysML offers no specific support for Time, it extends UML in several ways. Our time model has taken up two of these extensions: value property with units, and constraint block. A SysML value property defines a value with units, dimensions, and probability distribution. A SysML constraint block contains equations expressing constraints between value properties. The usages of the constraints in an analysis context are represented in a parametric diagram (kind of diagram absent in UML).

4) Non OMG profiles

Several UML profiles, which are not responses to an OMG RFP, are dealing with time. None of them supports multiform time.

EAST-EEA an ITEA project on Embedded Electronic Architecture [START_REF] East-Adl | The EAST-EEA Architecture Description Language[END_REF] provides a development process and automotive-specific constructs for the design of embedded electronic applications. Temporal aspects in EAST are handled by requirement entities. In theory, concepts of Triggers, Period, Events, End to End Delay, physical Unit, Timing restriction, can be applied to any behavioral elements. In practice, some of these concepts, such as the event triggering, make the timing analysis very complex. In the EAST-ADL (Architecture Description Language) document, it is recommended to use event triggering carrefully or even to avoid it.

The UML profile Omega-RT [START_REF] Graf | A real-time profile for UML[END_REF] focuses on analysis and verification of time and scheduling related properties. It is a refinement of the SPT profile. The profile is based on a specific concept of event making it easy to express duration constraints between occurrences of events. The concept of observer, which is a stereotype of state machine, is a convenient way for expressing complex time constraints. Note that the Omega Event is different from the UML Event, which poses a compliance issue. TURTLE-P [START_REF] Apvrille | TURTLE-P: a UML profile for the formal validation of critical and distributed systems[END_REF] is a UML profile for the formal validation of critical and distributed systems. This profile introduces temporal operators and composition (parallel, sequence, synchronization, and preemption). It deals with temporal indeterminism, usual in distributed systems. Properties of a TURTLE-P model can be evaluated and/or validated thanks to the formal semantics given in RT-LOTOS.

C. Time modeling in MARTE

MARTE is a response to the OMG RFP to provide a UML profile for real-time and embedded systems [START_REF] Omg | UML profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE)[END_REF]. MARTE is a successor of SPT, aligned on UML 2, and with a wider scope. MARTE introduces a number of new concepts, including time concepts, which are central to this paper. The main MARTE extensions of UML for timerelated concepts are gathered in Table 1 and informally described below. A detailed description of the MARTE's Time model is available in a research report [START_REF] André | Modeling Time(s) in UML[END_REF], and will be soon published on the www.promarte.org site along with the full MARTE specification. In this paper, we focus on the concepts (domain view) rather than the formal UML specification of the profile (UML view).

The underlying model of time is a set of time bases. A time base is an ordered set of instants. Instants from different time bases can be bound by relationships (coincidence or precedence), so that time bases are not fully independent and instants are partially ordered. This partial ordering of instants characterizes the time structure of the application. This model of time is sufficient to check the logical  2007 IEEE correctness of the application. Quantitative information can be added to this structure when quantitative analyses become necessary. Note that a specification of a temporal behavior may refer to points of time (instants) or to segments of time (durations). In the MARTE metamodel of time, Instant and Duration are two distinct concepts, specialization of the abstract concept of Time. The users of MARTE have access to the time structure through clocks. Here, clocks are not physical devices; they are model elements representing a general concept of time. While in SPT, clocks were implicitly bound to the physical time, in MARTE, a clock can be bound to any recurrent event. Thus, MARTE distinguishes two kinds of clocks: the chronometric clocks, which make reference to physical time, and the logical clocks, which focus on the ordering of instants, possibly ignoring the physical duration between instants.

Multiform time is defined and used in reactive synchronous languages [START_REF] Benveniste | The Synchronous Approach to Reactive and Real-Time Systems[END_REF], [START_REF] Benveniste | The Synchronous Languages 12 Years Later[END_REF]. It considers that flows (of event occurrences) are measured with different time units. At the design level, we know that actions take different amounts of time, but we don't know yet how much each one would take [START_REF] Benveniste | Algebraic Techniques for Timed Systems[END_REF]. Usually, time units are bound to physical time, but this is not necessary as illustrated below, where angular degrees are used as time units for crankshaft revolutions.

ClockType (Table 1) is a special class that specifies the nature (dense or discrete) and the kind (chronometric or logical) of the represented time, a set of clock properties (e.g., resolution, maximal value…), and a set of accepted time units. For the chronometric clock types, time units are the usual time units: the second (s) and its derived units. Most logical clock types use a generic time unit called tick. In some cases, they may use more specific units: a processor cycle, for instance, or even units for physical quantities, like in the illustrative example of this paper, where time is measured in angular degree (°). This license to choose (logical) time units is a direct consequence of our decision to model multiform time. A Clock (i.e., an instance of a ClockType) is characterized by its unit and the values (real numbers) given to its optional properties: resolution, maximalValue, offset. resolution gives the granularity of the clock; maximalValue is the value at which the clock will roll over; offset specifies the origin instant. All the values are given with the unit of the clock. A predefined Clock is provided in the TimeLibrary of MARTE: idealClk. This hypothetical clock reads the dense "physical time". It is used as a reference clock for the (imperfect) chronometric clocks defined by the users of the profile. A ClockConstraint sets dependencies up between clocks.

The idea behind the MARTE time model is that timerelated concepts (e.g., event occurrences and behavior executions) make explicit reference to one or several clocks, through the on property (Table 1), as illustrated below, on events and behaviors. In UML, an Event describes a set of possible occurrences; an occurrence may potentially trigger effects in the system. A TimeEvent is an Event that defines a point in time (instant) when the event occurs. The specification can be either absolute or relative to some other instant. A TimedEvent is a TimeEvent, where the instant specification explicitly refers to a clock. Moreover, if the event is recurrent, a repetition period (duration between two successive occurrences of the event) may be specified. In UML, a Behavior describes a set of possible executions; an execution is the performance of an algorithm according to a set of rules. MARTE associates a duration, an instant of start, an instant of termination with an execution, these times being read on a clock. A TimedProcessing is a Behavior or an Action with explicit references to clocks.

Examples on the use of these concepts are given in the next section.

III. APPLICATION TO AN AUTOMOTIVE SYSTEM

This section presents an automotive application: an ignition control and the knock correction in the case of a 4stroke engine.

A. Spark-ignition engine

In a 4-stroke engine, a cycle is characterized by four phases: Intake, Compression, Combustion and Exhaust. These phases are driven by the camshaft, the positions of which are measured in angle degree (°).

Since the spark plug needs a delay to produce a flame front in the combustion chamber, the electric spark must be generated before the theoretical ignition point (ITDC: Ignition Top Dead Center).

During the compression phase, at the Ignition Decision Point (IDP), an electronic control system determines the best angular position to generate an electric spark for igniting the compressed air-fuel mixture. The actual process is a bit more complex and involves remarkable points shown in Figure 1. The basic ignition advance angle (BIAA) is a function of the actual engine speed and the air/fuel ratio. Some corrections are then performed according to additional parameters leading to the actual ignition advance angle (AIAA). The angle from ITDC to AIAA is called the advance.

 2007 IEEE

B. An example of correction: the knock

The knock is a physical phenomenon that generates an auto ignition during the combustion phase and leads to a lost of efficiency of the engine, a consumption increase, and may cause irreversible damage to the cylinder. More details about spark ignition engine management and knock control system can be found in an automotive handbook [START_REF]Bosch Automotive handbook[END_REF].

IV. MODELING BEHAVIOR WITH MULTIFORM TIME

The ignition engine management is a typical example of real-time application gaining from a multiform time modeling.

A. Clock modeling and multiform time events

In a UML state machine, a label on a transition specifies a trigger that must reference an event. Labels like "after d" or "at i" implicitly defines a TimeEvent. The former specifies a relative instant, the later an absolute instant; these instants implicitly reference physical time. In MARTE, this convenient notation is extended to multiform time events, by applying the TimedEvent stereotype. In a 4-stroke engine, the succession of the phases is triggered by events associated with angular positions of the camshaft, not with physical time instants. In a multiform time approach, angular positions of the camshaft are considered as (logical) instants read on a logical clock: camClk. This clock represents a discrete logical time, its unit is defined as °CAM (degree cam), its resolution is 0.5 (for instance), its offset is 0, and its maximalValue is 360. All the values are implicitly given in °CAM, the unit of the clock.

The events that trigger the transitions in the state machine shown in Figure 2 are stereotyped by TimedEvent, with the tag value on set to camClk. For instance, event IC (Intake closes) triggers the transition from Intake to Compression; it is a TimedEvent occurring 90 °CAM after entering state Intake. Note that in Figure 2, the whole state machine, which is a UML Behavior, has been stereotyped by TimedProcessing. The events involved in the state machine are, by default, bound to the same clock (i.e., camClk).

The 4StrokeEngineCycle state machine is a simplified specification of the behavior. In actual engine, the Intake and the Exhaust phases are overlapping. We specify this behavior using a UML interaction. Usually, interactions are shown as UML sequence diagrams. Instead, we use its variant called timing diagram, introduced in UML 2.0. Identifiers on vertical dashed lines are event identifiers. For clarity, we have highlighted them in red, but this is not normative. A timing diagram focuses on condition changing within and among life lines along a (horizontal) time axis. Of course, in MARTE this kind of diagram are extended to multiform time. Instead of using the camClk, introduced above, we define a new logical clock: crkClk (crank clock), with °CRK (degree crank) for unit. This clock is bound to the rotation of the crankshaft. Since a full 4-stroke cycle needs two revolutions of the crankshaft, the maximal value of this clock is 720 °CRK. Its resolution is assumed to be 0.5 (for instance).

 2007 IEEE

The camshaft and the crankshaft are mechanically bound: the latter runs twice faster than the former. Consequently, the two clocks camClk and crkClk are tighly dependent; this dependency is expressed by a ClockConstraint. Figure 4 shows the relationships between the instants of the two clocks. The ClockConstraint says that camClk is a subclock of crkClk, with instants of camClk being coincident with every second instants of crkClk. The concrete syntax for this clock constraint is "camClk = crkClk filteredBy 0b( 10)", where 0b( 10) is a periodic binary word [START_REF] Cohen | N-Synchronous Kahn Networks -A Relaxed Model of Synchrony for Real-Time Systems[END_REF] standing for 1010…. (the infinite repetition of the 10 sequence). Note that having a logical clock does not prevent quantitative information: the instant value 0.5*(k-1) mod 720 °CRK is attached to the k th (k=1,2,…) instant of crkClk. For instance OTDC stands for Overlap Top Dead Center, which is the event occurring at the beginning of the cycle when the crankshaft is at its upper position. @t OTDC is a time observation of this event that denotes an instant (here the instant 0 on crkClk). The expressions written between curly braces are time constraints: they restrict the possible instants of occurrence of events. For instance, the occurrence of the TimedEvent EC is constrained by { t OTDC + [5..20] }. This constraint means that on crkClk and with the values given in °CRK, t OTDC + 5 ≤ t EC ≤ t OTDC + 20.

B. Multiform time behavior

In real-time applications, the behavior executions are generally temporally constrained. A deadline imposed on the termination of an execution is a usual constraint that can be specified either by a duration (maximal execution time) or by an instant (occurrence of a timeout event). Here again, MARTE provides facilities to express such constraints on multiform time models. This is the object of this section. The activity diagram in Figure 5 specifies the behavior of the ignition control, at a high-level of description. The first action determines the basic ignition advance angle (BIAA) by a table lookup with two input parameters: the current air/fuel ratio and the current engine speed (i.e., the rotational speed of the crankshaft). The BIAA data is then used by the Corrections action which takes into account various factors. Only one, the knock intensity (KI), is shown in this study. The Corrections action yields two results: the corrected ignition advance angle (CIAA) and information on the knock acquisition window, described below. The last action generates the actual advance (ADV). This sequence of actions is triggered at the ignition decision point (IDP, already presented in Figure 1). The IDP event occurs at a fixed angular position, therefore at a fixed instant on the crkClk. The new advance value must be available, under any circumstances, before another angular event (MIAA-Maximal Ignition Advance Angle) which corresponds to the worst case (i.e., maximal engine speed and maximal allowed advance). Thus, the duration of the execution of the main ignition control activity must be less than angle δm of Figure 1. This multiform time duration constraint is written in a constraint compartment of the activity frame (Figure 5) and it references crkClk. The main ignition control (MICtrl) activity is just a part of the ignition control (ICtrl) activity (Figure 6). The various corrections can be computed concurrently. For simplicity, we consider only the knock correction. The knock sensor is a vibration sensor that is sampled at 100 kHz (a classical frequency for vibration analysis). The use of a frequency unit makes implicit reference to physical time. In this application, as in many other control applications, logical clocks and chronometric clocks have to live together.

 2007 IEEE
The activity diagram in Figure 7 represents the behavior of the knock control (KCtrl). The behavior is triggered by the occurrence of the ITDC event (i.e., when the crankshaft is at its top dead center at the end of the compression phase). This event occurs at a fixed instant (360 °CRK) on crkClk. The WaitWS action waits for the delay KAWS (Knock Acquisition Window Start, part of the KAW data). The knock signal acquisition action (KSA) is then carried out. The two events KWB and KWE denote the start and the end of this action. The acquisition fills in a buffer that is then read by the Filtering action. The knock intensity (KI) is the result of the filtering. The acquisition terminates either when the buffer is full or when the knock acquisition window duration (KAWD, part of the KAW data) has elapsed. The first occurring event causes the effective termination. This is a multiform time constraint. The latter condition is measured in °CRK while the former is bound to physical time through the imposed sampling period. This non standard time expression mixing different kinds of time, is typical of our multiform time approach. The constraint is specified by: { t KWE -t KWB = min ( sampleNb * Tsampling on idealClk, KAWD on crkClk) }, where sampleNb is the maximal number of samples in the buffer, Tsampling is the period of sampling (10 μs since the sampling frequency is 100 kHz), idealClk is a predefined MARTE model element standing for the ideal chronometric clock, KAWD is the knock acquisition window duration, a value given in °CRK and dynamically computed by the Corrections action (Figure 5). In order to evaluate this constraint, we have to know a clock constraint between idealClk and crkClk. This is detailed in the section on heterogeneous time constraint (Section V.B).

C. Usage

When considering an engine with four cylinders instead of a single cylinder, constraints become stronger. The ignition control activity (ICtrl) represented on Figure 6 must be executed for each cylinder. However, each cylinder has its own clock: crkClk1, crkClk2, crkClk3 and crkClk4. The clock becomes a parameter of the activity. Furthermore, each one of these clocks is very similar to each others. The commonalities amongst these clocks are defined by the ClockType CRKClock; each cylinder clock becoming an instance of CRKClock. The offset of each clock is different and determined by the engine firing sequence (order of combustion). For an engine whose firing sequence is 1, 3, 4, 2, the offsets of the clocks are respectively 0, 180, 540 and 360 for crkClk1, crkClk2, crkClk3 and crkClk4.

The dependencies are not limited to a simple sequencing of activities, we must also take into account hardware resources involved. The next section addresses this issue.

V. TIMING ANALYSIS Section IV has introduced three clocks: camClk, crkClk and idealClk, and their dependencies expressed using constraints. Section V demonstrates the kind of analysis that can be performed on such constraints. We distinguish two kind of analysis. Analysis involving only one clockhomogeneous time constraints-and analysis involving several clocks-heterogeneous time constraints-. In the latter case, most of the time the constraints cannot be resolved.

A. Homogeneous time constraints

Each cylinder has its own storage for the knock intensity (KI), so there is no additional constraint coming from there. However, the buffer is shared by all cylinders. That means the filtering operation for one cylinder must complete before the start of the acquisition for the next firing cylinder. Looking at the specifications of the system, it is stated that  2007 IEEE the knock acquisition window will begin before 55°CRK (KAWS) and that it will last 55°CRK (KAWD) at most. In the worst case, the whole operation will complete in under 110°CRK. With a four-cylinder engine, each cylinder has 180°CRK at most to complete (720°CRK divided by 4), which leaves us with 70°CRK more than required.

If we consider now the case of a six-cylinder engine each cylinder has 120°CRK at most to complete the computation (720°CRK divided by 6), which still leaves us 10°CRK more than required.

Finally, if we consider the case of a eight-cylinder engine, we only have 90°CRK to complete the computation (720°CRK divided by 8), which is not enough in the worst case (when the engine is running at its highest rotational speed). In this case, one solution may be to use two buffers in alternance. One of them is used to store samples about the cylinder currently in the combustion phase while the other one is used to process corrections for the previous cylinder.

B. Heterogeneous time constraints 1) Mono cylinder case

For an engine the maximal speed of which is 4500 rpm (revolutions per minute), since a revolution is 360 °CRK, the maximal engine speed is (4500/60)*360 = 27000 °CRK/s, so that 1°CRK ≥ 37 μs. This inequality is a constraint between the two clocks idealClk and crkClk.

Constraint on idealClk and crkClk: 1°CRK ≥ 37 μs

There are also constraints induced by the data flow specified in the activities. For instance, in the knock control activity, the buffer is a critical resource written by KSA, and read by Filtering. The timing diagram (Figure 8) shows that the filtering in cycle k has to deliver the knock intensity before the occurrence of the ignition decision point of the next cycle (IDP k+1 defined in Figure 1). IDP k+1 is at a fixed angular position (e.g., 665 °CRK after the ITDC k or equivalently 55 °CRK before the ITDC k+1 ). Given the maximal values of the knock acquisition window start (KAWS max ) and the knock acquisition window duration (KAWD max ), we deduce that Filtering.duration ≤ 665 -KAWS max -KAWD max With the realistic values KAWS max = KAWD max = 55 °CRK, we get Filtering.duration ≤ 555 °CRK, which corresponds to 20.535 ms at the maximal engine speed. This constraint is easily satisfied by a microcontroller implementing the Filtering action.

2) Multi cylinder case

As shown in the homogeneous time constraints subsection, when several cylinders are considered, the duration constraints may become much more stringent. For instance, with a 4-cylinder engine, Figure 8 has to be modified, leading to Figure 9. We believe that multiform time is of first importance to specify constraints in real time embedded systems. In this paper, we have presented concepts essential to take into account this notion of multiform time.

UML is more and more present in the industry to bridge the gap between the domain experts, the customers and the developers. We have used UML to describe an example borrowed from the automotive domain and we have shown that with minor syntactic additions we can capture enough information so as to perform multiform-time analysis. We have partially validated requirements on the ignition control system. Some are related to performance and cost requirements (processor speed, number of buffers and their size); others are variability requirements (number of cylinders). The studied example is mainly control-dominated without considering timed communications, which are of major concern in automotive applications. This issue has to be addressed in the future.

The MARTE Time model is not restricted to the automotive application domain. It has been defined for the specification of time aspects in real-time embedded systems at large. We have tried to keep syntactical changes as small as possible to be able to reuse existing models, to preserve  2007 IEEE legacy and so as the business domain is not altered too much. However, the semantic shift is quite important since the notation can address a very large family of problems where time becomes a first class citizen.

Figure 1 .

 1 Figure 1. Ignition parameters

  The knock control system detects and corrects this phenomenon. It consists of one or several noise sensors, and a controller, which performs the acquisition and computes the correction. Acquisition of the noise sensor signals is carried out during an observation window (KAW-Knock Acquisition Window). The starting point (KAWS-KAW Start) and the duration (KAWD-KAW Duration) of the window may vary. They depend on the knock intensity (KI) measured during the previous combustion phase. The knock controller is an adaptive system. A digital filtering is applied to the signal samples to deduce the knock intensity. This value is then used to adjust the advance (advance correction).

Figure 2 .

 2 Figure 2. State machine of a 4-stroke engine cycle

Figure 3 .

 3 Figure 3. Timing diagram of a 4-stroke engine cycle for one cylinder Figure 3 describes the behavior of a 4-stroke engine.Instead of using the camClk, introduced above, we define a new logical clock: crkClk (crank clock), with °CRK (degree crank) for unit. This clock is bound to the rotation of the crankshaft. Since a full 4-stroke cycle needs two revolutions of the crankshaft, the maximal value of this clock is 720 °CRK. Its resolution is assumed to be 0.5 (for instance).

Figure 4 .

 4 Figure 4. Clock constraint between camClk and crkClkOn the timing diagram in Figure3, several events are named by acronyms explained in the lower part of the figure. For instance OTDC stands for Overlap Top Dead Center, which is the event occurring at the beginning of the cycle when the crankshaft is at its upper position. @t OTDC is a time observation of this event that denotes an instant (here the instant 0 on crkClk). The expressions written between curly braces are time constraints: they restrict the possible instants of occurrence of events. For instance, the occurrence of the TimedEvent EC is constrained by { t OTDC + [5..20] }. This constraint means that on crkClk and with the values given in °CRK, t OTDC + 5 ≤ t EC ≤ t OTDC + 20.

  /Fuel Ratio RPM: Engine speed ADV: Advance KI: Knock Intensity KAW: Knock Acquisition Window crkClk: crankshaft Clock MICtrl: Main Ignition Control BIAA: Basic Ignition Advance Angle CIAA: Corrected Ignition Advance Angle

Figure 5 :

 5 Figure 5: Ignition control for one cylinder (main part)

Figure 6 .

 6 Figure 6. Ignition control for one cylinder

Figure 7 .

 7 Figure 7. Activity diagram for the knock

Figure 8 .

 8 Figure 8. Knock acquisition and filtering timing diagram The events (ITDC, KWB…) are now indexed by the cylinder number; ITDC m , KWB m , KWE m and KID m refer to cylinder m, while ITDC n refers to cylinder n, the successor of m in the firing sequence. Note that the deadline for the KID is no longer IDP, but ITDC n . Instead of a duration of 665 °CRK between ITDC k and IDP k+1 , we have a duration of 720/4 = 180 °CRK between ITDC m and ITDC n , which leaves us with 180 -110 = 70 °CRK for the filtering duration in a 4-cylinder engine. Thus, at the maximal engine speed, the filtering duration should not exceed 70*37 = 2590 μs, much less than in the case of a single cylinder.

Figure 9 .

 9 Figure 9. Knock acquisition and filtering timing-multiple cylinder case

TABLE I .

 I MAIN MARTE TIME CONCEPTS

	MARTE concepts	Properties
	ClockType Clock ClockConstraint TimedEvent TimedProcessing	dense or discrete time chronometric or logical accepted units clock properties unit required or provided on: clocks on: clock every: Duration on: clock duration: Duration startEvent: Instant finishEvent: Instant

ACKNOWLEDGMENT

This study has been partially supported by the RNTL Memvatex project [20], which provides the application case study, and the project Usine Logicielle, sub-project OpenDevFactory [21], which supports the implementation of the MARTE Time profile.

The original publication is available at ieee.org (http://dx.doi.org/10.1109/SIES.2007.4297340).