Model-Driven Engineering of Simulations for Smart Roads Alberto Fernández-Isabel, Rubén Fuentes-Fernández Department of Software Engineering and Artificial Intelligence Univesidad Complutense de Madrid Madrid, Spain afernandezisabel@ucm.es, ruben@fdi.ucm.es Abstract The development of systems for SRs (and in general of ITSs) presents multiple challenges [Figueiredo et al., 2001] Smart Roads (SRs) are systems that provide traffic- [Varaiya, 1993] [Wang et al., 2006]. First, these are com- related services, based on a combination of sen- plex and distributed systems. They comprehend multiple and sor and actuator networks deployed in roads, vehi- heterogeneous software and hardware components. Their op- cles, and surrounding elements. They are complex erating conditions are changing and demanding, as they are distributed systems that involve multiple heteroge- frequently deployed over wide geographical areas and partly neous components and technologies. This makes outdoors. Among other issues, this implies that they have to their development a challenging and costly process. deal with the failure and redeployment of components, en- Simulations are a key tool to deal with these issues, ergy saving, and limited and intermittent connectivity. Sec- as they allow developing and testing in fully con- ond, they affect activities that involve living beings and un- trolled environments with simplified software com- controlled environments, so carrying out realistic and exhaus- ponents. Nevertheless, they still need to consider tive testing is difficult and expensive. multiple perspectives (e.g. experts and designers), Simulations help to mitigate the previous problems [Pur- which frequently cause problems to understand and sula, 1999]. With them, experts can control and observe the validate them. Model-Driven Engineering of sim- relevant variables of a problem, and designers perform an ulations appears as a solution. It uses models to incremental development of systems. However, simulations represent explicitly these perspectives, and trans- also present some important drawbacks [Axtell and Epstein, formations to link them and generate new artifacts 1994]. People involved in their development have different (including code). This paper presents a framework backgrounds, e.g. authorities, traffic experts, systems design- to develop simulations of SRs following this ap- ers, or programmers of simulations and control. It is difficult proach. Its base is an existing modeling language for them having a complete understanding of the simulation related to road traffic which is adapted to specify at the different levels of abstraction and its multiple facets. the aspects of these systems (i.e. sensors, networks, For this reason, there are frequent problems to validate that and services), and their context (i.e. users, vehicles, simulation results correspond to the initial requirements. and their environment). A process guides its use in the transition from abstract models to code sup- Model-Driven Engineering (MDE) [Schmidt, 2006] can be ported by tailored tools. A case study on a system used to address these issues [Fuentes-Fernández et al., 2012]. to track vehicles using sensors in roads illustrates In these developments, participants specify systems mainly its use. using models. Transformations perform recurrent modifica- tions of models and other artifacts, and describe mappings among them. In the case of simulations for SRs, traffic ex- 1 Introduction perts would model the abstract system (i.e. independently of specific platforms), and designers would ground it to specific The availability of affordable sensors and actuators suitable devices and target simulation platforms. Part of the transi- for traffic settings is leading experts to redesign the related tion between both groups of models could be automated with facilities. The goal is that they become smart environ- transformations. For instance, abstract sensors and actuators ments, able to gather and analyze information, and react to usually correspond to certain classes in the target platform. In it [Figueiredo et al., 2001]. Intelligent Transportation Sys- this way, the development of simulations becomes an iterative tems (ITSs) integrate these environments to provide services and incremental process of refining models and transforma- like [Figueiredo et al., 2001] [Varaiya, 1993] vehicle track- tions where all the information is explicit. Since models have ing, congestion detection, or identification of road conditions. a higher level of abstraction than code, and transformations In this context, Smart Roads (SRs) [Wang et al., 2006] are describe the relevant correspondences, this approach facili- systems where the key devices are those deployed in roads tates the exchange and discussion of information on simula- and their elements. tions and artifact reutilization. The adoption of MDE to develop SR simulations needs mers use the generator (adapted from [Fernandez-Isabel and to have available an infrastructure that includes several ele- Fuentes-Fernandez, 2015] and based on Eclipse [Steinberg et ments. Domain Specific Modeling Languages (DSMLs) de- al., 2008] frameworks) to map model elements to code tem- fine the vocabulary to specify models in a determined con- plates. These templates are fragments of code with marks cor- text. There must be also languages to describe transforma- responding to primitives of the DSML. Then, the code gen- tions, though here both specific Transformation Languages erator reads the models and mappings, instantiates the tem- (TLs) and general-purpose programming languages are used. plates, and generates the code of simulations. Participants need tools to work with these elements, such The case study that illustrates this approach is the simu- as model editors, transformation engines, or code genera- lation of the system in [Karpiriski et al., 2006]. That work tors. Finally, processes guide participants in developments presents an architecture with road sensors to track vehicles. with these elements. This work introduces a DSML for the This case study models the system and generates its code for high-level specification of simulations of SRs. Work with it the JADE agent platform [Bellifemine et al., 2007]. This il- is based on a process with tailored tools. lustrates how working in this way facilitates understanding The DSML is adapted from a previous one related to road the different aspects of the simulation and reduces the effort traffic [Fernandez-Isabel and Fuentes-Fernandez, 2015]. It is to code it. formed by three clusters according to the context they con- The rest of the paper is organized as follows. Section 2 sider: a behavioral cluster, an environment cluster and an in- makes an introduction to MDE. Section 3 presents the DSML, teractive cluster. The first describes the profiles and behavior while Section 4 the development guidelines of the proposal. of individuals, while the second takes into account the place Section 5 describes the support tools, and Section 6 applies where the simulation occurs and its elements. The last one the framework to the case study of tracking vehicles. Then, uses elements commonly used by Agent-Oriented Software Section 7 compares the approach and its results with related Engineering (AOSE) [Argente et al., 2009] (i.e. goals and work. Finally, Section 8 discusses the conclusions and future tasks) and a perception, evaluation, action cycle to represent work. the decision-making of individuals. New primitives are introduced to model the main elements of SRs. These are the sensors and actuators that provide 2 Background the interface of the system with the external world. That MDE [Schmidt, 2006; Kent, 2002] is an approach to software world includes people, their vehicles, and the environment. development based on models and transformations. Mod- The environment in turn includes, at least, roads, signals, els are specifications of information regarding the system to and general conditions (e.g. weather, daytime, or type of build. Transformations are automated modifications of mod- road). Part of these concepts are extracted from research in els and other artifacts to generate new products. In this con- related domains, including Agent-Based Modeling (ABM) text, developers work specifying their models incrementally, [Axtell and Epstein, 1994], traffic simulations [Fernandez- and running transformations to integrate models or perform Isabel and Fuentes-Fernandez, 2015], and sensor networks certain modifications (e.g. adding design information or gen- [Fuentes-Fernández et al., 2009]. erating code). All the information relevant for the develop- Most of elements in these problems are represented in the ment is thus presented as models or transformations, so devel- DSML as model elements. These are related to the original opers have it explicitly described. This improves traceability DSML or to SRs components, having the latter an internal between artifacts across development. Working effectively in state, and an interface with methods to consult and manipu- this way requires having support tools for certain tasks. late them. Examples of components are sensors, actuators, Models are described following Modeling Languages and vehicles. A particular type of element are the spots. (MLs) that establish their primitives and constraints, so all They represent components in the environment that can be developers can interpret them in similar ways. Model editors observed and manipulated by devices (i.e. sensors and actua- support developers when specifying models, and guarantee tors). For instance, a tracking magnetic sensor can detect the the compliance of models with their MLs. In order to allow passing of a bodywork spot of a vehicle. this functionality, MLs are defined formally. There are alter- SRs elements with complex behaviors are modeled as natives for this definition depending on the ML features and agents. They are defined in a similar way of individuals in- the context and needs of its use. Domain Specific Modeling volved in road traffic (i.e. in terms of the goals they pursue Languages (DSML) [Luoma et al., 2004] are MLs oriented and the information they have), and their capabilities to ma- only to one context. nipulate both their internal and the environment states. Graphical graph-oriented MLs are the most popular ones The language also includes general mechanisms of inher- in contexts such as Software Engineering and graphical sim- itance between concepts and definition of instances of types ulations. Their models specify graphs where entities are in the adaptation to SRs. They facilitate the modification to connected by links, and all of them can have related prop- different modeling needs through extensions of the language erties. Metamodels are the most widely used means to and the specification of simulations using models. specify these languages [Steinberg et al., 2008]. The de- The related tools are a model editor and a code genera- scription of metamodels relies on meta-modeling languages tor. Experts use the first one to specify graphically models such as the Meta-Object Facility (MOF), Ecore [Steinberg compliant with the DSML. It is based on the INGENME et al., 2008], or Graph-Object-Property-Relationship-Role [Pavón et al., 2011] meta-editor. Designers and program- (GOPRR) [Smolander, 1993]. MOF is used by the Object- Figure 1: Excerpt of the road traffic metamodel. Management Group (OMG) to define standards such as the [Fernandez-Isabel and Fuentes-Fernandez, 2015]. It is en- Unified Modeling Language (UML). Ecore is almost aligned hanced modifying its structure and introducing various ab- with Essential MOF, a subset of MOF. It is supported by the stract entities. The model element is the main one. It allows Eclipse communities related to MDE with a complete and describing elements from road traffic (e.g. profile and knowl- widely supported set of tools. GOPRR has a richer set of edge of individuals involved in traffic) and specific compo- primitives than the previous two languages, as it allows for in- nents related to SRs (e.g. sensors and spots). stance the direct definition of n-ary relationships. INGENME Regarding the naming, nodes are the meta-classes and links [Pavón et al., 2011] is a framework for it. are meta-relationships among them. Meta-relationships with The implementation of transformations has two main ap- triangles represent inheritance and with filled diamonds ag- proaches. They can be implemented as modules in main- gregation. The attributes and adornments of the previous el- stream programming languages; or they can be described ements are meta-properties. It is specified with a GOPRR with specific transformation languages and executed by an metamodel, being this notation similar to that also used in engine. The first approach reuses existing expertise and re- MOF and Ecore [Steinberg et al., 2008]. sources, and it is usually more efficient. Examples of it The original metamodel is introduced in Section 3.1 where are INGENME [Pavón et al., 2011] and the traffic simula- its structure and meta-classes are explained. The DSML ex- tion framework in [Fernandez-Isabel and Fuentes-Fernandez, tension developed to represent the SRs components is de- 2015], both based on Java and XML. The second approach scribed in Section 3.2. makes easier to examine the mappings between the source and target artifacts of the transformation. Examples of it are 3.1 Traffic DSML Eclipse projects such as JET and ATL [Steinberg et al., 2008]. This work adopts GOPRR as its meta-modeling language. The DSML is originally focused on modeling the behavior of Its tools are based on the INGENME MDE framework. individuals involved in road traffic (i.e. drivers, pedestrians and passengers). It is a flexible language that presents specific mechanisms to ease its fitness to the large amount of theories 3 Domain specific modeling language evaluated by traffic studies. The foundations of the DSML for SRs is adopted from It is described by a metamodel [Steinberg et al., 2008] another DSML focused on general purpose road traffic which provides a set of meta-entities in order to represent the ture. The main one is the general element from which the model element and the general relationship extend (see Fig. 1). The first acts as a basis for the traffic DSML and the SRs DSML parts and is extended to the behavioral element and the meta-classes involved in the interactive cluster. The behavioral element is the parent meta-class of the main el- ements (i.e. not components) that compound the mental and environment clusters. Component extended from it and is also the parent of the components of both clusters. The second supports introducing relations (e.g. affect or impact) between the rest of entities that are extended from model element. Another kind of hierarchies are considered in this part of the metamodel. In the both mental and environment clus- ters composition hierarchies are introduced between main el- Figure 2: Information and ModelElement related elements. ements (e.g. profile or vehicle) and their respective compo- nents (e.g. pcomponent or vcomponent). These components can be decomposed into others of the same type, promoting the creation of complex structures. 3.2 DSML extension to SRs This module of the DSML is mainly focused on people mov- ing in their vehicles in roads unless there are other elements in the environment such as traffic signals, obstacles, and weather. These elements can be observed with sensors, and systems that can actuate on them using actuators. The DSML makes of these concepts its core categories. Elements are modeled in terms of the information they manage. There are two basic types of information: facts are Figure 3: Environment and Container related elements. internal to elements, and events can be perceived from out- side. The root concept that embraces both modules of DSML notions, relationships, properties and explicit constraints. is the ModelElement entity (see Fig. 2). In this case, it is Metamodel concepts are inspired in AOSE [Argente et al., characterized in terms of an identifier, an internal state, an in- 2009] and are classified into three clusters. The mental clus- terface compose of methods, and the events it can generate. ter (i.e. profile, knowledge and their components) is based on The internal state is a set of facts. A method is defined by [Shinar, 1978] and considers the features and internal state of its parameters and results, which are information. It can also individuals. The environment cluster (i.e. environment, ve- have execution conditions defined in terms of their parame- hicle and their respective components describes the elements ters and the internal state of its model element. Methods can extracted from DVE model [Amditis et al., 2010]. The inter- be internal (only accessible from the component) or external active cluster (i.e. evaluator, executor, goal and task) repre- (accessible from other components). sents the decision-making of individuals. It includes a per- The environment meta-class of the traffic DSML is related ception, evaluation, and acting cycle. to a set of elements over a map. These are the places, and Regarding the metamodel bedrock, it revolves around the can be located in sections or junctions. Examples of places person notion (see Fig. 1). It symbolizes a kind of human are things in the environment, like the road surface or protec- being involved in road traffic. According to their means of tive fence. Environment has attributes (e.g. AvailableArea) to transport and how they interact with them, these people can store the relevant information of the map. This latter is rep- take different roles (i.e. drivers, passengers, or pedestrians). resented through a graph that describes the road sections that Thus, person are able to interact with an environment. This link two junctions (one when the section in an entering or exit interaction is immediate (for pedestrians) or indirect (in the point). case of drivers and passengers). The information people have Places contain spots (see Fig. 3). These are the compo- is illustrated with the knowledge, while their features are rep- nents that sensors can actually observe and where actuators resented by the profile. The purposes of people involved in can act upon. For instance, a vehicle have several spots, e.g. traffic are described by goals, and the actions to carry out the bodywork, the electronic system, or the engine. Sensors them by tasks. Evaluators study the information obtained and actuators constitute the interface of systems with the ex- from the environment and decide how the individuals must ternal environment. They run on containers attached to spots. act according to it. Tasks for achieving their implicit instruc- Besides this, a sensor is linked by the perceives relationship tions are picked up by an executor. to the spot it observes, and an actuator by the actuates re- The metamodel uses inheritance hierarchies with the pur- lationship to the spot it affects. In both cases, sensors and pose of providing notion specializations and a flexible struc- actuators access to the external interface of the spot, i.e. they use its external methods. For instance, a rain sensor runs in a cific works, most of them conceptualize agents in terms of container of the bodywork, where it perceives the raindrops mental entities and communication capabilities, and consider from an abstract weather spot. The containers of a system the existence in their environment of artifacts they can use. are linked through communication channels. This common core facilitates the transition from abstract to Beyond these elements, complex entities related to SRs are design models with transformations. modeled as agents. Typical agents are the controllers of sen- The first stage is organized around the services that the SR sors and actuators. The control of components can be repre- should provide. It starts identifying potential services pend- sented directly with their methods, but controller agents are ing to specify (activity 1). If there are any, work follows with recommended when there are complex algorithms and com- its definition in terms of the information it needs and it pro- munication with other controllers. vides, and the actions it should take (activity 2). This infor- Similarity to a person (see Fig. 1), an agent has an identi- mation and actions appear in elements of the system and its fier, and goals that it can achieve through tasks that manipu- environment that next activities specify. late information. As the environment of SR systems is unpre- The service interacts with spots, either observing or chang- dictable, the execution of a task can fail or not to produce the ing them. Experts identify them and their potential contain- expected results. Thus, a goal defines satisfaction conditions ers, and specify them as model elements (activity 3). in terms of information to indicate when it has been fulfilled. The service also communicates with spots using the sys- Tasks can be organized (or decomposed) into others ac- tem sensors (described in activity 4) and actuators (in activ- cording to the traffic DSML (see Fig. 1). Also, they can be ity 5). These devices are initially specified as model elements. linked to methods related to the information they produce and In case that their functioning needs complex control or com- consume. In this way, tasks can use methods of components, munications with other containers, they also need controller including sensors and actuators. agents. Channels must be added for those containers that Agents communicate among them using notifications. need to be linked. These are a type of event addressed to a certain agent identi- The spots identified in previous activities are located in el- fier. ements of the SR environment. These elements are places, Agents behave internally following a perceive-reflect-act vehicles (considered in activity 6), persons (activity 7) and (in cycle. First, they execute those tasks that imply access to activity 8) other components from environment (i.e. ecompo- external components (e.g. sensors and other elements related nents). All of them are specified as model elements. They to SRs) to gather data. Then, they update their internal state, also have a location in the environment. Thus, these activities both facts and goals. Finally, they pre-select for execution also define the map and locate the places in it. those tasks that can satisfy some of their still non-fulfilled The last element to specify is the behavior of individuals goals. Among them, they choose one to actually execute. (in activity 9). It is defined in terms of the goals and tasks The external elements that agents can access are those adapting existing road traffic theories [Fernandez-Isabel and linked to them using manages relationships. For controllers, Fuentes-Fernandez, 2015], and the steps of the perception, these relationship can be only with other elements in their evaluation and acting cycle. As people act on the environ- containers. In contrary, persons can relate only to sensors ment, tasks to check the actual result of their actions and and actuators from containers, or other elements outside con- update its information must be included (e.g. route path or tainers like vehicles or components in the environment. position in the environment). This part of the language also includes some general mech- When all the services have been identified, the process can anisms applicable to most of the previous concepts. It sup- move to the design of the simulation. Transformations map ports inheritance of concepts and relationships to allow their abstract to design models (activity 10). These transformations specialization. For instance, the concept of component can can be reused when they are available from other projects have additional and different features according to the target with the same target AOSE methodology. Then, the design simulation platform. models act as the initial specification for the simulation in that methodology (activity 11). For instance, our work can be 4 Development guidelines easily linked to the INGENIAS AOSE methodology [Pavón et al., 2005]. The INGENME [Pavón et al., 2011] infrastruc- The framework to develop SR simulations provides guide- ture our work uses is the same of INGENIAS, and both share lines to model using the previous DSML and support tools. similar definitions of concepts such as agent, goal, task, and They include 11 activities. The process is decomposed in two fact. different stages. The first one (nodes 1-9) is focused on the expert work and specifications with the proposed DSML. The second one (nodes 10-11) deals with the design of simulation. 5 Support tools After concluding the first one with the specific infrastructure This MDE approach uses two development tools to achieve of this work, the second part can be addressed with a MDE the different steps of the process (see Section 4). A model ed- methodology for general software development. Given that itor based on INGENME supports the specification of models our DSML oriented to SRs follows ABM [Axtell and Epstein, compliant with the DSML. It is the main tool of the first stage. 1994], methodologies from AOSE are a suitable choice [Ar- For the second stage, most of AOSE methodologies have gente et al., 2009]. Both ABM and AOSE make of agents their own tailored model editors and transformation tools. their core concept. Though there are differences among spe- Here, the last steps of code generation are achieved with a Figure 4: Excerpt of the simulation model for the system to track vehicles. Stereotypes indicate DSML types. code generator adapted from [Fernandez-Isabel and Fuentes- perceive car passing. Nodes know their relative order and dis- Fernandez, 2015]. Then, designers specify graphically the tance to others. They make up an ad-hoc network to exchange mappings from elements in models to classes in the target information, so they can determine the position and speed of platform. The generator outputs the simulation code from vehicles. this information. The first stage of the process generates the abstract model The INGENME model editor is based on INGENIAS of the simulation with the DSML. Fig. 4 shows part of it. methodology. It present a graphical canvas where models Activities 1 and 2 identify the services the SR offers. The can be captured. The resulting outcome can be exported as definition of the problem points out only to the tracking vehi- a XML file. It promotes the modularity of the proposal and cle service. Activity 3 identifies the spots related to it. There the ability to maintain the independence among the different are two. The sensors are placed in eye cats in the road bor- artifacts created. ders. These sensors track the passing of vehicles sensing their The code generator is a graphical tool implemented in Java metal, for instance in their bodywork. Activities 4 and 5 con- which provides an engine to generate source code from a sider the related sensors and actuators. There are magnetic model specification. In this case, the specification comes in tracker sensors, but no actuators. The specification of car ve- form of XML file from the model editor. This tool is mainly hicles in activity 6 does not consider any particular feature of focused on easing the work to developers. In order to that, it them. In the proposed DSML, decisions regarding maneuvers provides an intuitive navigation through the elements of the are placed in persons. Activity 7 models them. The original models, and uses multiple wizards to guide the users in the work does not introduce any specific model of drivers. The achievement of the most complex tasks. It also takes as input problem also identifies elements in the environment (see ac- a metamodel, code templates compliant with it and libraries tivity 8) and models them in particular as ecomponents (see from the target simulation platform. The templates support Section 3.1) or places (e.g. road borders). the preliminary automated code generation while the libraries The previous first round allows identifying the main con- can be used to adapt the simulation platform to the models cepts of the problem, and their types and relationships. A sec- requirements. To achieve it, the tool offers the possibility ond round is focused on their state and functionality. Given of creating new classes (empty or extended) through which that individuals with driver role and their actions trigger most producing a new simulation platform specialized in specific of activities in the system, the analysis starts with them. models [Fernandez-Isabel and Fuentes-Fernandez, 2015]. A simple path-following behavior is proposed for persons with driver role. Following a perception, reflect and acting 6 Case study cycle (no evaluation is considered), there is a first step of cal- This section applies the previous framework (see Sections 3 culating position and a second of moving. The first one corre- and 4) to develop the simulation of one of the services for SRs sponds to goal got info and task sense, and the second to goal described in [Karpiriski et al., 2006]. It is a vehicle tracking ended route and task move (see Fig. 4). Sense generates the service based on magnetic sensors located in nodes of cat eyes fact perceived position consulting the method toSense. This every few meters in road borders. These sensors are able to fact is compared with the fact route to determine if the car has arrived to its destination. That is the satisfaction condition of considered in the proposed DSML, though the use of com- goal ended route. If the goal is unfulfilled, the task move can ponents, agents, and information makes possible setting up be triggered. It calls a method toMove that updates the car richer models than in other works. The DSML also offers and its fact position. extension mechanisms frequently disregarded in other works. In the system, several elements do not have specific state In most cases, there is no information about the adopted or methods, as only their location is relevant. This is the case development process (see for instance the already mentioned of road border and eye cat. In order to have a precise location works). However, this is a key aspect to evaluate approaches of sensors, road borders are modeled as multiple elements of regarding, for instance, ease of adoption and modeling or this type, each one with its own location. costs. When there is some information on that [Pursula, 1999] The eye cat spot has node containers for the sensors and [Kotusevski and Hawick, 2009], it usually shows approaches controllers of the system. The magnetic tracker sensor trig- with a manual transition from abstract models to code, and gers events when it perceives a car. Its magnetic controller focused on the later. The advantages of MDE in this con- has a task pass car to sense that event (see Fig. 4), and gener- text were pointed out in the introduction: explicit definition ates through the toPass method a car passed event addressed of all the information related to that transition, which facil- to a central tracking controller (not shown in the diagram). itates its discussion and reutilization, and support tools for This would implement the services for end users described it. There are already some works in this line in the context in [Karpiriski et al., 2006]. Given the constraints imposed of traffic studies [Fernandez-Isabel and Fuentes-Fernandez, by the DSML, the model needs to introduce a tracking node 2015] [Vangheluwe and De Lara, 2004]. Their main differ- container for this last controller. In order to enable commu- ences with our work are their focus and purposes (general nication between controllers in different containers, these are traffic versus SRs) and the use of infrastructures less adopted connected with a road channel. than ours (in [Vangheluwe and De Lara, 2004] graph rewrit- The previous discussions has not considered the map. The ing grammars for transformations), which hinders their adop- studied work focuses on two-way single carriageways. With tion. the DSML, these correspond to junctions that connect at least two sections, one for each direction. Crossroads are junctions 8 Conclusions and future work that connect more sections. The previous model elements (ve- hicles and road borders) are placed in them. This paper has introduced a framework for the model-driven These steps complete the first stage and the abstract model development of simulations of SRs. It is based on a DSML of the simulation. Activity 10 maps the abstractions of that and tailored standard infrastructures. model to those of INGENIAS [Pavón et al., 2005]. Then, The DSML adopts a previous one focused on road traf- activity 11 follows the steps of this methodology adding the fic that integrates concepts from studies and simulations of design information required for the JADE platform [Bellifem- traffic [Fernandez-Isabel and Fuentes-Fernandez, 2015]. It ine et al., 2007]. There are several entities of the DSML with is adapted through ABM concepts (e.g. agents) [Axtell direct mappings to JADE: agent to agent and task to behavior. and Epstein, 1994] and elements related to sensor networks Others need to be mapped to specific ad-hoc classes. This is [Fuentes-Fernández et al., 2009]. Based on a general concept the case of the model elements, facts, goals, spots, sensors of model element (could be a modeling entity or a component and actuators. Their implementation only requires attributes with state and an interface that manipulates information), it and methods to get and set their values, as agents manage the introduces new concepts related to sensors, actuators, spots updates of the simulation state. in the environment and vehicles. A higher level of abstrac- tion comes from agents, which are used to describe complex controllers. 7 Related work The framework also proposes a development process based The presented framework is mainly related to the modeling on this DSML. It comprehends a specific first stage to spec- and development of SRs. This section discusses existing al- ify the abstract models of simulations, and connects with an ternatives for them. AOSE MDE methodology [Argente et al., 2009] for the low Under the label of SRs literature presents a variety of level design and code generation. A model editor based on complex heterogeneous systems [Figueiredo et al., 2001] INGENME [Pavón et al., 2011] and a code generator sup- [Varaiya, 1993] [Wang et al., 2006]: they provide different ports it. This latter is a graphical engine based on wizards services, for a wide range of users, and integrating multiple that allow guiding users in some of the complex steps of the devices. Nevertheless, several common elements can be ab- development process. stracted in most of them [Varaiya, 1993] [Wang et al., 2006] The case study has shown how a simulation can be speci- [Sun et al., 2006]. There are sensors and actuators embed- fied to a large extent with the DSML, including the behavior ded in an environment that includes roads and their elements, of its components. Only algorithms to manipulate informa- weather, vehicles, and sometimes people. Vehicles and peo- tion are demoted to code templates. This approach focus de- ple are usually modeled focusing on their movement. In the velopment efforts on models and transformation, which can case of simulation [Kotusevski and Hawick, 2009], works be reused more easily than code. offer more complex models of vehicles and people moving, The previous work has still several open issues. The SR with paths to follow and principles of movement (e.g. colli- module of the DSML needs extensions to consider aspects sion avoidance or observe traffic norms). These elements are such as time or specific constraints. There are studies on these issues but further work is required to integrate them. [Karpiriski et al., 2006] M Karpiriski, Aline Senart, and The process needs to incorporate additional advice on how to Vinny Cahill. Sensor networks for smart roads. In Per- use the DSML and deal with the design. In particular, that de- vasive Computing and Communications Workshops, 2006. sign should be consistent with the expected semantics of the PerCom Workshops 2006. Fourth Annual IEEE Interna- DSML. Finally, additional experiments are needed with other tional Conference on, pages 5–pp. IEEE, 2006. works and target platforms to validate the approach. Specifi- [Kent, 2002] Stuart Kent. Model driven engineering. In In- cally, the combination of road traffic theories and services for tegrated formal methods, pages 286–298. Springer, 2002. SRs taking advantage of the potential of the DSML described here (it is a general purpose traffic DSML adapted to SRs) is [Kotusevski and Hawick, 2009] G Kotusevski and KA Haw- another important next step to consider. ick. A review of traffic simulation software. Computer Sci- ence. Institute of Information and Mathematical Sciences, Acknowledgments Massey University, 2009. This work has been done in the context of the project Social [Luoma et al., 2004] Janne Luoma, Steven Kelly, and Juha- Ambient Assisting Living - Methods (SociAAL) (TIN2011- Pekka Tolvanen. Defining domain-specific modeling lan- 28335-C02-01) supported by the Spanish Ministry for Econ- guages: Collected experiences. In 4 th Workshop on omy and Competitiveness. Also, we acknowledge support Domain-Specific Modeling, 2004. from the Programa de Creacin y Consolidacin de Grupos de [Pavón et al., 2005] Juan Pavón, Jorge J Gómez-Sanz, and Investigacin (UCM-BSCH GR35/10-A). Rubén Fuentes. The ingenias methodology and tools. Agent-oriented methodologies, 9:236–276, 2005. References [Pavón et al., 2011] Juan Pavón, Jorge Gómez-Sanz, and [Amditis et al., 2010] Angelos Amditis, Katia Pagle, Adolfo López Paredes. The sicossys approach to sos engi- Somya Joshi, and Evangelos Bekiaris. Driver–vehicle– neering. In System of systems engineering (SoSE), 2011 environment monitoring for on-board driver support 6th international conference on, pages 179–184. IEEE, systems: Lessons learned from design and implementa- 2011. tion. Applied Ergonomics, 41(2):225–235, 2010. [Pursula, 1999] Matti Pursula. Simulation of traffic systems- [Argente et al., 2009] Estefanı́a Argente, Ghassan Beydoun, an overview. Journal of Geographic Information and De- Rubén Fuentes-Fernández, Brian Henderson-Sellers, and cision Analysis, 3(1):1–8, 1999. Graham Low. Modelling with agents. In Agent-Oriented [Schmidt, 2006] Douglas C Schmidt. Model-driven engi- Software Engineering X, pages 157–168. Springer, 2009. neering. COMPUTER-IEEE COMPUTER SOCIETY-, [Axtell and Epstein, 1994] Robert L Axtell and Joshua M 39(2):25, 2006. Epstein. Agent-based modeling: understanding our cre- [Shinar, 1978] David Shinar. Psychology on the Road. The ations. The Bulletin of the Santa Fe Institute, 9(2):28–32, Human Factor in Traffic Safety. John Wiley & Sons, 1978. 1994. [Smolander, 1993] Kari Smolander. Goprr: a proposal for a [Bellifemine et al., 2007] Fabio Luigi Bellifemine, Giovanni meta level model. University of Jyväskylä, Finland, 1993. Caire, and Dominic Greenwood. Developing multi-agent systems with JADE, volume 7. John Wiley & Sons, 2007. [Steinberg et al., 2008] Dave Steinberg, Frank Budinsky, Ed Merks, and Marcelo Paternostro. EMF: eclipse model- [Fernandez-Isabel and Fuentes-Fernandez, 2015] Alberto ing framework. Pearson Education, 2008. Fernandez-Isabel and Ruben Fuentes-Fernandez. Devel- oping an integrative modelling language for enhancing [Sun et al., 2006] Zehang Sun, George Bebis, and Ronald road traffic simulations. In Computer Science and Infor- Miller. On-road vehicle detection: A review. Pattern mation Systems (FedCSIS), 2015 Federated Conference Analysis and Machine Intelligence, IEEE Transactions on, on, pages 1745–1756. IEEE, 2015. 28(5):694–711, 2006. [Figueiredo et al., 2001] Lino Figueiredo, Isabel Jesus, [Vangheluwe and De Lara, 2004] Hans Vangheluwe and JA Tenreiro Machado, J Ferreira, and JL Martins Juan De Lara. Computer automated multi-paradigm De Carvalho. Towards the development of intelligent modelling for analysis and design of traffic networks. In transportation systems. In Intelligent Transportation Proceedings of the 36th conference on Winter simulation, Systems, volume 88, pages 1206–1211, 2001. pages 249–258. Winter Simulation Conference, 2004. [Fuentes-Fernández et al., 2009] Rubén Fuentes-Fernández, [Varaiya, 1993] Pravin Varaiya. Smart cars on smart roads: Marı́a Guijarro, and Gonzalo Pajares. A multi-agent problems of control. Automatic Control, IEEE Transac- system architecture for sensor networks. Sensors, tions on, 38(2):195–207, 1993. 9(12):10244–10269, 2009. [Wang et al., 2006] Fei-Yue Wang, Daniel Zeng, and Li- [Fuentes-Fernández et al., 2012] Rubén Fuentes-Fernández, uqing Yang. Smart cars on smart roads: an ieee intelli- Samer Hassan, Juan Pavón, José M Galán, and Adolfo gent transportation systems society update. IEEE Perva- López-Paredes. Metamodels for role-driven agent-based sive Computing, (4):68–69, 2006. modelling. Computational and Mathematical Organiza- tion Theory, 18(1):91–112, 2012.