EDONA/HMI – Modelling of Advanced Automotive Interfaces
Upcoming SlideShare
Loading in...5

EDONA/HMI – Modelling of Advanced Automotive Interfaces






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

EDONA/HMI – Modelling of Advanced Automotive Interfaces EDONA/HMI – Modelling of Advanced Automotive Interfaces Document Transcript

  • E DONA / HMI – Modelling of Advanced Automotive Interfaces S. Boisg´ rault1 , E. Vecchi´ 1 , O. Meunier2 , J.-M. Temmos3 e e 1: CAOR, Math´ matiques et Syst` mes, Mines ParisTech, 60 boulevard Saint-Michel, 75272 Paris, France. e e 2: Intempora, 2 pl. Jules Gevelot, 92130 Issy les Moulineaux, France. 3: Visteon Software Technologies, 1800 route des Crˆ tes , 06906 Sophia Antipolis, France. e Abstract: Screens are becoming the most important support advanced in-vehicle applications such as driv- media for information systems in vehicles. They en- ing assistance, navigation systems, vehicle communi- abled a wide variety of new services such as naviga- cation, etc. Therefore high-end vehicles and car proto- tion systems, driver assistance or entertainment. They types benefit the most from this increasing flexibility. also are increasingly replacing the analog instrument While we present in this paper models and tools to clusters used to display classic vehicle information. design human-machine interfaces for such in-vehicle The design of user interfaces for such targets involves screens, due to its considerable diversity, we do not some usual requirements like rapid prototyping and address the full range of such systems. Embedded sys- interoperability. As these user interfaces present infor- tems with little integration with the vehicle functions – mation that may directly influence the driver’s behav- DVD players for example – may be considered as tra- ior, they shall also be handled as safety-critical soft- ditional consumer electronics products as far as inter- ware. face design is concerned. In this paper, we describe a model-based process for Despite a flexible and large design space that will the design of such interfaces that address these issues. be detailled in the next section, we also exclude from We present – in the context of the EDONA project1 – a our design scope some very specific interfaces that are domain-specific model for automotive interfaces that categories in their own right. For example, we do relies on graphic and functional standards. We then not consider integral design of 3D navigation systems describe a code generation architecture and runtime or video systems. Our framework however may be platform. used to design some parts of such systems as it will be Keywords: human-machine interfaces, automotive, demonstrated in the last section. domain-specific language, model-based design. What we address specifically is the direct extension of the instrument cluster concept: design of display components that represent the evolution of vehicle or 1 Introduction environment data in the most adequate way. Flexibil- ity in the design space is required to allow for specific Scope Definition. In car cockpits, screens are in- design accomodating traditional data (RPM, speed, creasingly present and used as media for the hosting of fluid levels, etc.) as well as advanced or even future human-machine interfaces (HMI). When they are used services. In this respect, the last section of the paper to display vehicle and environment data, these screens will present an interface focused on pedestrian safety, replace or complement the more traditional – analog an original source of data if any. As such information or digital – instrument clusters. This evolution is mo- systems may have a direct influence on the driver’s be- tivated by the flexibility of such systems: they can eas- havior, safety is an issue. The HMI design process and ily support the classic features of instrument clusters models shall therefore be amenable to safety analysis but are not limited to a specific component layout. Be- and certifications. yond this extra configurability, they also enable the de- Finally, due to the advanced nature of applications, sign of innovative and highly-specific interfaces that our solution is at ease with high-end graphic platforms would not be otherwise possible. Such interfaces may – typically TFT-LCD, full-color reconfigurable display 1 This work has been performed in the context of the EDONA with extensive 2D graphics library support. However project of the System@tic Paris R´ gion Cluster. EDONA is an Open e for simpler applications and low-end platforms (LED, Development Platform to Automotive Standards. It is supported by VFD, etc.), our framework can still be used for mod- the “Direction G´ n´ rale de la Comp´ titivit´ , de l’Industrie et des Ser- e e e e elling, simulation and specification but automatic code vices (DGCIS)”, the “Conseil R´ gional d’ˆle de France”, the “Conseil e ı G´ n´ ral des Yvelines”, the “Conseil G´ n´ ral du Val d’Oise” and the e e e e generation support is not available. “Conseil G´ n´ ral des Hauts de Seine”. www.edona.fr e e Issues. The design of this new generation of HMIs 1
  • model is a data-flow language described in the sec- tion 2.2, an execution model widely used in the design safety-critical systems. The details of their integration that forms the HMI meta-model is discussed in section 2.3. 2.1 Data-driven Scene Graph The graphics layer of the E DONA / HMI model is a 2D data-driven scene graph. A scene graph – or hierarchi- cal display list – is a structured collection of graphic nodes, commonly used in 2D and 3D vector graphics. It is ultimately composed of primitive nodes such as vector graphic shapes (lines, circles, etc.), images and text. On the other hand, compound nodes are node containers that structure the scene graph. All types of graphic nodes may be configured. Con- sider for example the text node definition textptext Ð “hello”, (1) Figure 1: A hybrid – mechanical and screen-based transform Ð rotatep90q, – instrument cluster. Displays may be used to fill Ð rgbp255, 0, 0q, reproduce the traditional features of mechanical family Ð “Helvetica”q systems (here RPM and speed dials) – as demon- strated in the top figure – but may also be easily Such an attribute assignment is used as a single reconfigured to display other kinds of vehicule in- and uniform mechanism to configure node core data formation. (‘text’), and the geometrical transformations (‘trans- form’) as well as style options (‘fill’ and ’family’) that raises several issues. Interoperability – the ability are applied to the node. to easily exchange components specifications and de- Some attributes used in this assignment are type- signs – is a major industrial issue. Also, as they specific: the ‘text’ data and font ‘family’ for example present information that may directly influence the are meaningless for all but text nodes. Other attributes driver behavior, these HMIs shall also be treated as are shared between several node types: the ‘fill’ color safety-critical software components. We propose here is applicable to all vectorial constructs and the geomet- a model-based approach that relies on a scene graph rical ‘transform’ to all graphic nodes. The list of all graphics layer and a synchronous functional layer. attributes applicable to a given node type is its context. Synchronous languages [9, 13, 3] are standard rep- The union of all such contexts is called the graphics con- resentations for safety critical software, they enjoy a text. clear and simple semantics that allows various pro- Finally, node definitions may be partial: although gram analysis like automatic test generation [15] or the ‘opacity’ attribute belongs to the text node context, model-checking [10]. An efficient design process and it does not appear in the node definition (1). Such un- the ability to do some rapid prototyping are crucial as defined values are to be interpreted as a convenience well. Our model comes together with dedicated tools mecanism for default values – 1.0 would be the opac- for the assisted design and the compilation of compo- ity natural default for example. They may also be used nents into executable graphics interfaces. to support context inheritance. We formalize briefly the structure of this scene graph grammar. More information about the set of 2 HMI Models node types and corresponding context attributes that we actually consider may be found in section 2.4. Let We formalize in this section the meta-model that un- P be the set of primitive node types, let g – the group – derlies the whole E DONA / HMI design process. The be the single compound node, and let G be the graph- HMI graphics content is described as a data-driven ics context. Our graphics model is given by the system  ppG Ð val , val , ¤ ¤ ¤ q, p € P scene graph, a powerful yet simple data model de- scribed in section 2.1. The document structure is fixed node 1 2 (2) and no graphics node is ever created at runtime ; | gpG Ð val1 , val2 , ¤ ¤ ¤ qxnodey (3) the model is therefore amenable to extensive analysis. This graphics layer is complemented with a functional | node1 , node2 (4) layer that provides a component model for HMI to be The notation pG Ð val1 , val2 , ¤ ¤ ¤ q is only a shortcut for handled at the proper abstraction level. The functional the graphics context assignment pai Ð vali | ai € Gq 2
  • as it appears in the example (1). We denote Gptq the we focus on issues that directly impact the HMI com- context of the node type t and u the undefined value. ponent model and the integration of its functional and The graphics context assignment G Ð val1 , val2 , ¤ ¤ ¤ in graphics layer. (2) is subject to the consistency constraint Scoping. Every statement defines implicitely input and output data flows determined by the functions I tai € G | vali $ uu € Gppq and O: and accordingly the same assignment in (3) to Ipflow  exprq  Ipexprq Ipnextpflow1 q  flow2 q  tflow2 u ¡ tflow1 u tai € G | vali $ uu € Gpgq Ipstmt1 , stmt2 q  pIpstmt1 q ¡ Opstmt2 qq‰ For the sake of simplicity, we may assume here that pIpstmt2 q ¡ Opstmt1 qq all context attribute values belong to the same value Ipstmt when flowq  Ipstmtq ‰ tflowu space. A concrete instance of value space would gather Ipconstantq  ∅ heterogeneous attribute types such as: Ipfctpflow1 , flow2 , . . .qq  tflow1 , flow2 , . . .u Ipflow1 ? flow2 : flow3 q  tflow1 , flow2 , flow3 u val  u (14) | int | float | matrixp3, 3q (5) and | text | color | fontname Opflow  exprq  tflowu A scene graph is in our terminology data-driven if the Opnextpflow1 q  flow2 q  tflow1 u value space used in (2) and (3) is composed of unde- Opstmt1 , stmt2 q  Opstmt1 q ‰ Opstmt2 q fined values and data flows. Opstmt when flowq  Opstmtq val  u | flow (6) (15) In order to gain an explicit control of the signals visi- During the HMI execution, the functional layer – a bility we add an extra construct – the component – to data-flow program whose structure is described in the the list of available statements (7-10). section 2.2 – computes the graphics state: the set of con- crete values that are substituted to the data flows. In stmt | cpinputs, outputsqxstmty (16) this data model, the structure and nodes of the graph- Components input and output flows are given in their ics document are given but the graphics state is muta- declaration: ble. Ipcpinputs, outputsqxstmtyq  inputs Opcpinputs, outputsqxstmtyq  (17) outputs 2.2 Functional Model In the E DONA / HMI model, the graphics state is driven Components interface definition (16) is subject to the by a synchronous data-flow program, formally de- following consistency conditions: fined by the following grammar: inputs … Ipstmtq and outputs „ Opstmtq (18) stmt  flow  expr (7) | nextpflow1 q  flow2 (8) 2.3 HMI Model – Integration | stmt1 , stmt2 (9) The HMI model integrates the graphics and functional | stmt when flow (10) models defined in the sections 2.1 and 2.2. The core object of HMI models is the HMI element. It is either a The ‘,’ operator denotes concurrent execution of state- graphics node or a functional statement. ments, ‘next’ the delay operator and the ‘when’ con- struct represents conditional execution. Our actual functional model also has default values for constructs elt  node | stmt (19) (8) and (10) so that data flow values are always well Graphics and functional definition of (2, 4, 6) and (7- defined. This feature is not presented for the sake of 13) are modified so that their right-hand side accept simplicity. For the same reason we do not discuss typ- hmi elements instead of nodes and statements. ing issues: expression expr are either constants, func- Graphics nodes being now integrated with the func- tion calls or the “if-then-else” construct: tional layer, data flows from the functional layer may expr  constant (11) drive the graphics state evolution. From the functional point of view, primitive node provide the following | fctpflow1 , flow1 , . . .q (12) data flows: | flow1 ? flow2 : flow3 (13) IpppG Ð val1 , val2 , ¤ ¤ ¤ qq  tai € G | vali $ uu We do not detail the well-known semantics of such OpppG Ð val1 , val2 , ¤ ¤ ¤ qq  ∅ data-flow programs but refer the reader to [4]. Instead (20) 3 View slide
  • how we extended it with appropriate HMI-specific constructs. Format Selection. The selection of SVG as the mod- elling language for the description of graphic content was driven by our research for solutions that would improve interoperability in HMI design. Despite sig- nificant differences, many leading solutions for em- bedded HMI design (such as VAPS XT, ALTIA Design or Scade Display [16]) have adopted a similar model- driven process. Their model for graphics share the most important structural features such as a tree-like document structure, support for affine transforms, ba- sic and complex shapes, styling, etc. They are how- ever based however on proprietary formats. On the contrary, SVG is an open and mature recommandation from the World Wide Web (W3C) consortium, an inter- national standards organization known for standards such as the XML technology. SVG is a language for describing two-dimensional Figure 2: The scene graph representation of a graphics in XML. While the original SVG – version gauge. As a data-driven scene graph, all but the 1.0 in 2001 – was designed to support vector graph- needle rotation attribute may be assigned con- ics on the Web, SVG version 1.1 is used nowadays for stant values. If the gauge is used as a speedome- all kind of vector graphics descriptions. It has a large ter, functional modelling may be used to convert feature set that proved to be suitable for the kind of the vehicle speed into an angle and to ensure that graphics content that was presented in section 2.1. It the maximal angle threshold is never exceeded. also has given birth to two standard subsets – named profiles in the SVG recommandation – SVG Tiny and SVG Mobile. They are specifically designed for mobile Finally, the graphics group defined in (3) and function devices, platforms that are primarily characterized by component defined in (16) are replaced by a single con- specific constraints in terms of CPU speed, memory struct – the hmi group component – that acts as a HMI size, color support, etc. The family of mobile devices element container and merges the graphics and func- obviously contains mobile phones and personal digital tional hierarchies: assistants but the target platforms for embedded HMI gcpgraphics, interfaceqxelty (21) in vehicles share similar constraints. The usage scenar- ios for those profiles explicitely include the modelling where of graphical user interfaces. graphics  G Ð val1 , val2 , ¤ ¤ ¤ (22) More generally, SVG 1.1 is not a monolithic standard  as it provides consistent policies to profile (restrict) and interface inputs, outputs (23) extend the standard in order to adapt to specific us- age scenarios. As SVG 1.1 is described as a set of in- Its inputs and outputs are given by: dependent modules, the definition of profiles is sim- ple. The standard extensibility policy recommands the Ipgcpgraphics, interfaceqxeltyq  use foreign namespaces to complement SVG data with inputs ‰ tai€ G | vali $ uu (24) application-specific content. The extra information is simply ignored by conformant SVG applications. This Opgcpgraphics, interfaceqxeltyq  outputs (25) policy is used effectively in generic SVG authoring This hmi group component interface (21) is subject to tools [12] and also in SVG models exported by some the consistency conditions (18). embedded interface designers. The existence of several SVG authoring tools makes 2.4 Model Format and Serialization the design of new HMI graphic content a simple task. SVG being an authoritative description for vec- The format used to represent HMI models – whose tor graphics, some HMI design tools used in the auto- structure was described in the previous sections – motive industry already have a partial support for it. has a considerable practical impact. In this section Therefore, the selection of SVG as a core format has the we present the motivations behind the design of the potential to increases interoperability between generic E DONA / HMI format, explain why we have selected a and application-specific design tools. Beyond existing subset of an existing graphics standard – Scalable Vec- authoring tools, we also greatly benefit from software tor Graphics (SVG) – as the basis for our format and libraries that support SVG such as the Apache Batik 4 View slide
  • SVG Toolkit [1]. Existing SVG software reduce the de- The data-driven scene graph model of section 2.1 is velopment cost of E DONA / HMI model editors as well described through the embedding of input XML el- HMI graphics rendering engines. ements into graphics node elements that specify the E DONA / HMI SVG profile. We finally adopted a context attribute they act upon. Although this is an custom mobile profile, very similar to SVG Tiny 1.1. aspect of the model that was not described in the pre- This profile brings a welcome simplification with re- vious sections, a symmetric output element exists to spect to the full standard. Notably, the style of graphic make available the initial graphics state to the func- nodes can only be set through individual XML at- tional layer. tributes – called presentation attributes – and not the Functional expressions (constants, function calls ‘style’ or CSS styling mecanism. This simplification al- and the “if-then-else” construct) as well as the delay lows a uniform implementation of context assignment operator are mapped to XML elements and conditional in data-driven scene graphs. The handling of numer- execution is handled at group component level exclu- ical data is also simpler because length data have no sively. Functional expressions have explicit input and units and always refer to the local coordinate system. outputs interfaces. Sharing data flows between state- Text graphics nodes are also more manageable because ments is handled by a list of links in the parent com- a single style can be applied to them. ponent element. This simple block-diagram model The study of HMI design use cases has also taught allows easy generation and processing of functional us that the SVG Tiny profile supports almost every model at the expense of a verbose XML model. In par- features we needed and conversely that many of the ticular, no micro-language is used to encode functional graphics elements and context attributes that have information in attributes as the SVG format does for been removed (filters, the support for ”group opacity”, path, transform, etc. so that all functional processing etc., see [17] for a detailled list of supported constructs) may be done with standard XML tools. were costly to render and not adapted to the context A standard library of functions has also been de- of dynamic document rendering. We have only rein- fined. It contains the classical logic, numeric and com- troduced three features that all belong to the full SVG parison operators. It also provides text processing 1.1 specification: gradients, opacity and clipping. We function and type conversions operators between nu- however limit them to their simplest form: gradients meric and text types – the only primitive types that and opacity constructs are supported as in the SVG we actually consider. SVG array-like attributes – such Tiny 1.2 candidate recommandation and clipping as in as ‘path’ and ‘transform’ – are not handled with spe- SVG Basic 1.1. We believe that this set of constructs cific types. Instead they are either considered as text is currently a good trade-off between model simplicity attributes and as such are fully mutable or considered and the support for a large range of HMI models. as numeric arrays with a fixed structure, the numeric content being then their only mutable part. On the other hand, we exclude from the E DONA / HMI profile the support for declarative animation of SVG Tiny 1.1: the kind of dynamic docu- 3 E DONA / HMI Software Tools ment that these constructs allow are strictly contained in our full HMI model provided that a ‘time’ input Tool support is crucial to ensure the success of the is available to HMI components. On the other hand, E DONA / HMI model. Our E DONA / HMI Prototyping the data-driven model support direct update of the toolchain includes a set modelling tools, a generator of graphic state that cannot be expressed within the HMI software components and a runtime architecture time-based model. based on J AVA. This platform is specialized for sim- Data Flows Format. The E DONA / HMI format ex- ulation in the design loop, component testing and de- tends the SVG graphics format to make the scene ployment on car prototypes, particularly hosts of intel- graph data-driven and to describe functional con- ligent systems transportation (ITS) applications. While structs. The extension design is compatible with the runtime component of this platform is not com- W3C recommandation and enables conformant SVG patible with usual embedded systems constraints, it is interpreters and viewers to properly process all HMI open-source and intended to simplify the generation graphics content. First of all, all data flow elements of E DONA / HMI components for such targets. belong to the E DONA / HMI namespace http://www. edona.fr/hmi namespace, so that non-graphic data 3.1 Model Management are ignored during SVG processing. Then, instead of mapping group components to an XML element in the Several types of software contributions were made E DONA / HMI namespace, we implement them as a svg to support the E DONA / HMI design process. Among group that contain an XML element with local name them, a schema-based validator that checks the con- ‘component’ in the E DONA / HMI namespace. As a con- sistency of XML model files against the E DONA / HMI sequence, graphic content in group components are grammar, several gateways between E DONA / HMI always visible to SVG interpreters and properly pro- models and other formats, as well as internationaliza- cessed as groups. tion tools and a documentation generator. 5
  • Moreover, a Python library was developed that per- part of HMI components is straightforward: it con- forms XML data binding on HMI model files: it au- sists in a model simplification step (see section 3.1) tomatically establish a mapping between HMI model followed by a code generation step. Code generation constructs and Python classes. This library was de- is a simple matter for such data-flow models where signed to be a suitable basis for many E DONA / HMI- static scheduling information is available [4]; its is also related development – for example, to speed up the more efficient at runtime than an interpreter when development of a HMI model editors. Internally, it many low-level operations are performed. More im- was used for automatic generation of HMI models portantly, in the context of HMI model prototyping, it and model transformations. The need we had to start is also simpler to implement: the complexity of hier- with models that may be incorrect – for example with archy and conditional activation have been eliminated SVG constructs that do not belong to the mobile pro- in the model simplification step while these constructs file – or are not complete models and will not be un- have to be maintained in the interpreter scheme. til the final steps of their design – has motivated the The optimal execution policy for the graphics part of design of a lazy data binding scheme where instances HMI component is a more complex issue and largely of E DONA / HMI constructs are only bound when they depends on design process and target requirements. are effectively accessed. As a consequence, it may be For HMI as software components in a context with used as the foundation of a validators that goes be- strong embedding and safety constraints, the simplic- yond grammar-level consistency checks. ity, size and performance that result from an exten- The XML data binding library is also used in the sive code generation process is likely to be preferred. early stage of the code generation process: the func- A typical code generation would then linearize the tional layers of HMI models are simplified into equiv- scene-graph and translate graphic primitives into calls alent models with no hierarchy and no conditional ac- to a low-level hardware-accelerated graphics platform tivations. Graphic constants that feed the functional such as OpenGL ES, a subset of OpenGL that targets layer are also extracted to fully decouple the functional embedded platforms. Considering the SVGL toolkit, model from the graphics one so that the functional an OpenGL based SVG library, display lists can also be code that is generated is testable and also supports the used to drastically speed up rendering performances master-slave model explained in the next section. for static parts of an SVG document [5]. On the other hand, in the context of simulation in the design loop, testing and prototyping, the availability of debugging 3.2 Runtime Architecture information and model snapshots, complete with the HMI execution policy. Both graphics and functional current graphics state is crucial. Due to the complexity part of HMI components may be generated with dif- of the actual graphics model, maintaining in memory ferent execution policy, the two extreme choices be- the graphics data in a structure similar to the model is ing either a full interpreter architecture that executes the simpler strategy. The significant performance loss the model at runtime or a more extensive code gen- that may result from this strategy may be partially off- eration phase that produces model-independent exe- set by pre-rendering of the static graphics content – cutable programs. We discuss in this section the pros something the E DONA / HMI model is totally suitable and cons of both options. for. The E DONA / HMI Prototyping component genera- tor therefore uses a mixed strategy: J AVA code is gen- erated for the functional layer whereas the graphics model is interpreted and rendered using the B ATIK SVG toolkit – a component of the A PACHE XML G RAPHICS project – in a way that updates of the graphics model are always accessible through a stan- dard XML API. This strategy allows – at any time dur- ing execution – to serialize the state of a HMI compo- nent as a new model and also allows for several graph- ics backends: no graphics (for testing purposes), J AVA AWT and image buffer. There also exist some alternatives to the B ATIK SVG toolkit, including the SVGL toolkit as mentioned ear- lier using OpenGL as backend. The RSVG library is also a SVG toolkit based on Cairo, a software li- Figure 3: architecture of the E DONA / HMI Proto- brary used to provide a vector graphics-based, device- typing runtime independent API for software developers. Cairo is de- signed to provide primitives for 2-dimensional draw- Our strategy for the generation of the functional ing across a number of different backends and it is de- 6
  • signed to use hardware acceleration when available. HMI runtime interface. A pure synchronous inter- face for HMI components would be conceptually sim- ple: a sequence of activation signals, coming with new values for the HMI inputs, would trigger an execution step for the functional layer and at the same time up- date of the HMI graphics. However this scheme would have a severe drawback: by synchronizing the render- ing of the graphics with the input flow, it may impose a fast rendering cycle, beyond what the target is able to execute due to the cost of this step. In the most com- mon use case, a fixed frame rate is given that provides a sufficient quality in the user experience and no extra rendering steps should be performed, or the rendering should be synchronized with an external video stream. For other situations, such as execution for testing pur- poses, rendering is a step that should occur on specific Figure 4: EDONA-LOVe interface for the safety of breakpoints or explicit demands, the functional layer pedestrians being most of the time the only active component. Therefore, to avoid unnecessary performance issues 4 Conclusion and provide the needed flexibility, to the synchronous activation signals is added a – possibly asynchronous We presented the E DONA / HMI design process for the – rendering signal. To ensure the correctness of exe- design of Human-Machine Interfaces on screens in car cutions, a duplication of the graphics state is required cockpits. This method successfully addresses typical in the functional component so that every new set of industrial issues in the domain of HMI design: in- input values may update the graphics state. This state teroperability, proper modelling, flexibility and rapid is however only transferred to the graphics layer upon prototyping. In addition to the design process effi- request. This partial decoupling and resulting layers ciency gain, our solution enables to promote the de- architecture is depicted in figure 3. sign process of HMI in cars to the same level as other safety-critical domains like avionics or power plants. Safety-critical issues are addressed by relying on a data driven scene graph model for the graphics part and a 3.3 Intelligent Transportation System Use synchronous model of computation for the functional Case part of the E DONA / HMI system. Finally, to adress the needs of intelligent transporta- tion systems (ITS) embedded applications, we ex- References tended the B ATIK SVG toolkit to support the display of graphic and textual information as video overlays [1] Apache XML Graphics – Batik SVG Toolkit. as well as the inclusion of embedded controls. A full- http://xmlgraphics.apache.org/batik/. fledged HMI was also designed for the LOV E [7, 14] [2] S. Boisg´ rault, M. O. Abdallah, and J.-M. Tem- e project. LOV E aims to use multi-sensor tracking sys- mos. SVG for automotive user interfaces. In SVG tem to improve the road safety for pedestrians. Our Open, Nuremberg, Germany, 2008. HMI interface was used to display video streams and – through specifically designed interfaces – data such [3] F. Boussinot and R. de Simone. The Esterel lan- as pedestrians location and risk of collision. Real- guage. IEEE, 79(9):1293–1304, 1991. time data acquisition and management is performed by RTMaps2 , as well as the communication with the [4] P. Caspi, D. Pilaud, N. Halbwachs, and J. Plaice. HMI stack. LUSTRE: a declarative language for program- ming synchronous systems. In POPL ’87: Proceed- This use case validated our approach, showing its ings of the 14th ACM SIGACT-SIGPLAN sympo- expressivity to quickly create custom components, and sium on Principles of programming languages, pages the possibility to quikly integrate these components 178–188, New York, NY, USA, January 1987. into a full consistent system. External video streams ACM. were also integrated, showing its capacity to interface with an asynchronous environment. [5] S. Conversy and J.-D. Fekete. The svgl toolkit: en- abling fast rendering of rich 2d graphics. Tech- 2 “Real-Time Mutisensor Advanced Prototyping Software”, ´ nical Report 02/1/INFO, Ecole des Mines de http://www.intempora.com. Nantes, janvier 2002. 7
  • [6] EDONA: Environnements de d´ veloppement ou- e verts aux normes de l’automobile – website. http://www.edona.fr. [7] G. Gate, A. Breheret, and F. Nashashibi. Central- ized fusion based algorithm for fast people detec- tion in dense environment. In Proc. of the IEEE In- ternational Conference on Robotics and Automation, Kobe, Japan, May 2009. [8] N. Halbwachs. Synchronous programming of reac- tive systems. Kluwer, 1993. [9] N. Halbwachs, P. Caspi, P. Raymond, and D. Pi- laud. The synchronous dataflow programming language LUSTRE. Proceedings of the IEEE, 79(9):1305–1320, September 1991. [10] N. Halbwachs, F. Lagnier, and C. Ratel. Program- ming and verifying real-time systems by means of the synchronous data-flow language LUSTRE. IEEE Transactions on Software Engineering (TSE), Special issue: Specification and Analysis of Real-Time Systems, 18(9):785–793, September 1992. [11] Human Machine Interface – Work Package 4. EDONA HMI Format. Report, EDONA, 2008. [12] Inkspace - open source scalable vector graphics editor. Technical report. http://www.inkscape. org/. [13] P. Le Guernic, T. Gauthier, M. Le Borgne, and C. Le Maire. Programming real-time applications with SIGNAL. IEEE, 79(9):1321–1336, 1991. [14] LOVe: Logicield’Observation des Vuln´ rables, e project website. http: //love.univ-bpclermont.fr. [15] V. Papailiopoulou. Automatic test generation for lustre/scade programs. In ASE ’08: Proceedings of the 2008 23rd IEEE/ACM International Conference on Automated Software Engineering, pages 517–520, Washington, DC, USA, 2008. IEEE Computer So- ciety. [16] The standard for the development of crit- ical embedded display software. http: //www.esterel-technologies.com/products/ scade-display/. [17] Mobile SVG Profiles: SVG Tiny and SVG Basic. W3C recommendation, W3C, June 2009. http: //www.w3.org/TR/SVGMobile/. [18] Scalable Vector Graphics (SVG) 1.1 specifica- tion. W3C recommendation, W3C, January 2003. http://www.w3.org/TR/SVG. 8