dataesr/scientific-paragraphs-categorization huggingface dataset:
Additionally, it is important to support instantaneous response to dynamic road situations and neighboring vehicles through the efficient and delay-bounded data communications. This is possible through dedicated short-range communications (DSRC), such as IEEE 802. 11p. The driving safety can be further improved by leveraging a cooperation with infrastructure nodes (e. g. road-side units (RSU) and relay nodes) and other nodes (e. g. smartphones and Internet of Things (IoT)). Therefore, the construction of the vehicular sensor networks in vehicles and stationary infrastructure nodes is vital for providing the overall safety. The vehicular sensor networks for driving safety can include media access control (MAC) protocols, data forwarding schemes, and routing protocols for unicast, multicast, and broadcast, transport layer protocols, and security services (e.
Two wireless communication systems, such as ZigBee and 3G modules, are utilized in the system. ZigBee is used so that the data collector can transfer accelerometer sensing data to the car-mounted terminal. 3G is used so that the car-mounted terminal can transfer the accelerometer sensing data and GPS positioning information to the processing system in the cloud server. The processing system uses an acceleration-IRI model to calculate IRI, and a GPS-based distance algorithm is used to segment the measured road per 1 km. Various results are saved in an Oracle database in the cloud server, displayed on the digital map, and made available to a mobile terminal. For the proof of concept, multiple field tests of the prototype system were conducted in Huzhou, Zhejiang province in China. The experiment results indicate that the relative error of this proposed system is less than 10% for the laser roughness testing method that is a legacy approach using expensive hardware.
This paper at first proves that a locationbased optimal task assignment is a non-deterministic polynomial-time hard (called NP-hard) problem. To solve this challenging problem, this paper suggests a heuristic algorithm for a mathematical model of multivehicle collaborative task assignment problem. This algorithm considers each vehicle's time budget constraint and location, and also the requirements of sensing tasks. The heuristic algorithm performs an approximation location-based task assignment in two steps. The first step determines the allocation order among the engaged vehicles. The second step schedules an optimal sensing path for each individual vehicle. With Lingo software and simulations, this paper shows the efficiency of the proposed optimal sensing path scheduling algorithm for the crowdsensing task assignment.
Funding The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This research was supported by  Basic Science Research Program  through the  National Research Foundation of Korea (NRF)  funded by the  Ministry of Science, ICT & Future Planning  (no. 2014006438 ). This research was supported in part by  Global Research Laboratory Program  ( 2013K1A1A2A02078326 ) through  NRF.
Some of these ideas were already coarsely described or mentioned in our previous work on omniscient debugging  [9]. The remainder of the paper is organized as follows: -Section 2 presents background information on executable domain-specific modeling languages. -Section 3 motivates the problem domain by looking at the state of the art and explaining our ideas for overcoming existing limitations. -Section 4 gives an overview of our approach. -Section 5 presents our approach for generating multidimensional and domain-specific trace metamodels. -Section 6 explains the generation of trace constructors to make use of generated trace metamodels. -Section 7 presents our customization mechanism for tailoring trace metamodels to the application context of an xDSML. -Section 8 presents the implementation of our approach within the language and modeling workbench GEMOC Studio.
In this paper, we only deal with operational semantics, although our work can be directly adopted to translational semantics as long as a mechanism is provided to translate back the results of the execution (e. g. , the execution states) into the source domain  [12]. To define the execution state of a model, we consider that the abstract syntax metamodel of an xDSML can be extended into an execution metamodel with new properties and metaclasses. To this end, a mechanism equivalent to the well-known package merge operation of UML and MOF  [53, 56]  can be used. Note that in practice, existing tools and approaches use different but similar extension mechanismse. g. , Kermeta  [40]  uses aspect weaving, xMOF  [49]  uses generalization, Hegedüs et al. [35]  use separate metaclasses. Next, we call execution transformation the model transformation that changes the execution state of a model.
We consider this transformation to be endogenous (i. e. , both input and output models conform to the execution metamodel) and to be composed of a set of transformation rules, each defining a subset of the changes performed on the execution state. Depending on the model transformation language paradigm, rules can take different forms: In a declarative language, such as VIATRA  [18]  and ATL  [39] , they are composed of a source pattern and a target pattern and are executed using pattern matching; in imperative languages, such as Kermeta  [40]  and xMOF  [49] , they are operations that can call one another, one being the entry point starting the transformation. To avoid having to duplicate most of the model for the execution, we consider this transformation to be in-place (i. e. , the executed model is directly modified).
g. , determining how many tokens traversed a Petri net place). In the former case, manipulations are simple and the structure or content of the trace has little influence on the complexity of the analysis task. However, in the latter case, manipulations handle domain-specific data that can be arbitrarily complex depending on the considered xDSML. Hence, in such cases, defining the right analysis can be errorprone and difficult. A good illustration of these issues is semantic differencing  [43]. First, it is a hard problem because traces tend to be large and therefore expensive to process. But more importantly, semantic differencing consists in performing domain-specific analyses of traces, since they are written in accordance with the semantics of a specific xDSML, and may therefore rely on complex domain-specific data and properties.
Limitations of existing trace formats and approaches For a long time, considerable effort has been made to define both a variety of trace formats and approaches to define new trace formats. We call trace format a data structure describing the content of execution traces. With this term, we include metamodels (as defined in Sect. 2. 1), but also ASCII or binary formats, which can all be used in practice for trace construction, persistence (i. e. , serialization into files or storage into a database system) or analysis. 9 In the following paragraphs, we highlight the limitations of different categories of formats and we present crosscutting problems they all share. Existing generic trace formats. Few approaches  [7, 21, 32, 43, 63]  allow the capture and the manipulation of generic traces for any kind of execution from any kind of xDSML.
By doing so, an execution state would only contain the data necessary for performing trace analyses, which suggests better scalability in memory, better usability, and a smaller trace construction overhead. In a nutshell, our proposal is an approach to automatically generate a multidimensional and domain-specific trace metamodel specific to an existing xDSML, and possibly also specific to a set of trace analyses. To evaluate our approach, we consider a comparison to a linear generic trace metamodel that relies on the cloning of the complete executed model after each execution step, and that does not provide advanced navigation facilities. We evaluate the relevance of our contributions with respect to the following research questions: RQ1.
Observations and technical challenges There are many possible ways to generate a domain-specific trace metamodel for an xDSML. Regarding the execution states, a simple yet working idea is to reuse the complete execution metamodel of the xDSML in the trace metamodel. As the executed model conforms to the execution metamodel, we can clone it at each execution step and store it as a state in the trace. While we presented such approaches in Sect. 3. 2, we present below their limitations in more detail. First, by cloning the whole model to store each execution state, redundancies appear between the states regarding all static fields (as they never change) and certain dynamic fields (as they may not change in each step). This impacts both usability (RQ3) and memory consumption (RQ2), although the scalable model cloning approach that we presented in  [7]  would mitigate this issue by sharing static data among clones at runtime.
While most changes made during a big step are made by its substeps, some intermediate changes can be made directly by the big step itself, i. e. , outside of the substeps. For instance, a big step rule may start by making a change to the execution state before calling a first small step rule. Even though such change is not explicitly isolated within a dedicated transformation rule, it is nonetheless technically a small execution step. We call such anonymous small step an implicit step. These steps are taken into account by creating one dedicated metaclass per big step rule (lines 20-23 of Algorithm 4). In the case of Petri nets, it is possible for the run operation to be responsible for other model changes in between the calls to fire. Figure  5  depicts such situation: Before and after calling fire, the code of run might be responsible for model changes, annotated (1) and (  2 ).
Example of a trace constructor As we previously explained, we do not provide in this paper a complete code generation algorithm for trace constructors. Instead, we present a simplified example of a trace constructor generated for the Petri net xDSML introduced in Fig. 1 , and we use it to explain the logic behind the expected generation procedure. Algorithms 5, 6, 7 and 8 show the trace construction operations generated for the Petri net xDSML introduced in Fig. 1. These operations comply with the generic interface we introduced above, and they construct an execution trace conforming to the execution trace metamodel generated for Petri net shown in Fig. 4.
For instance, the fire step rule shown in Fig. 2  can be modified to call both addState and addStep at the very beginning, and both addState and finishStep and the very end. -A model or program transformation can be defined to automatically make similar modifications to each step transformation rule of the transformation. -Aspect oriented programming (e. g. , AspectJ) can be used to specify pointcuts at the beginning and at the end of all step rules to call the trace constructor. -If the considered model transformation language provides a notification mechanism to listen and react to applications of transformation rules (e. g. , xMOF virtual machine, @Step annotation in Kermeta), a listener can be defined to call the operations of the trace constructor when step rules are applied. -If the considered execution environment relies on a dedicated execution engine responsible for applying the transformation rules, this engine can produce calls to the trace constructor in between the applications of the rules.
Motivation and objective Trace metamodels generated with the proposed approach provide domain-specific and optimized data structures for capturing exhaustive data about the behavior of executed models. Therewith, a trace metamodel generated with our approach provides the basis for realizing any kind of trace analysis for a given xDSML. In this paper, we call a specific set of trace analyses to be applied on traces obtained from the execution of any model conforming to a given xDSML application context. An application context is specific to the considered xDSML and concerns any model conforming to this xDSML. Depending on the considered application context, only a subset of the exhaustive data captured by execution traces constructed with our approach may be required to perform the desired trace analyses.
Implementation in the GEMOC Studio We implemented the three parts of our approach within the GEMOC Studio, namely the generation of trace metamodels, the generation of trace constructors, and the use of tracing annotations. All the code for this work is open-source (EPL 1. 0 licensed), and can be found in publicly available source code repositories. 14   Implementation of the generators. We implemented our trace metamodel and trace constructor generators for the GEMOC Studio using the Eclipse Modeling Framework (EMF) and the programming languages Xtend and Java. The input of our generators consists of an xDSML defined using Ecore for the abstract syntax, and using either Kermeta or xMOF for the operational semantics. The output is an Eclipse plugin containing the execution trace metamodel defined using Ecore, and an execution trace constructor written in Java and relying on EMF libraries.
Our generators can be called from the graphical user interface to trigger the generation for an xDSML defined in the language workbench of the studio. Implementation of generated trace constructors. As we have mentioned previously, a trace constructor generated by our implementation takes the form of an engine add-on that is deployed in the GEMOC Studio modeling workbench. This greatly simplifies the integration of the trace constructor with the execution transformation, as the engine only is responsible for notifying add-ons about the progress of the execution. Therefore, the trace construction add-on must simply be enabled, and no modifications of the execution transformation are required for enabling the construction of traces. Implementation of tracing annotations. To represent tracing annotations as defined in Sect.
Case study As explained above, we have evaluated our approach on multidimensional and domain-specific execution traces in a case study on semantic model differencing. For this, we have adapted our semantic model differencing framework  [43]  to analyze multidimensional domain-specific execution traces instead of generic clone-based ones. 16 onsidered xDSML. Based on this adapted semantic differencing framework, we have performed a case study on the real world xDSML foundational UML (fUML)  [55]  that we presented in Sect. 7. 2. For this, we have first defined the execution semantics of fUML in an operational way with xMOF  [49]. The execution metamodel of fUML extends one metaclass of the language's abstract syntax metamodel and defines 58 dynamic metaclasses, as well as 56 dynamic properties.
As a consequence of the defined tracing annotations, the size of the generated multidimensional and domainspecific trace metamodel is reduced to two metaclasses for capturing values of dynamic fields, ten metaclasses for capturing object states,  17  and 39 metaclasses for capturing execution steps. 18 The associated generated domain-specific trace constructor is composed of 832 lines of Java code. Semantic differencing rules. In our previous work  [43] , we had defined a set of semantic differencing rules for fUML based on a generic and clone-based trace metamodel. These rules were defined using the Epsilon Comparison Language (ECL)  [42]. We have adapted these rules to carry out the semantic differencing on multidimensional and domainspecific traces, instead of generic and clone-based ones.
Our main hypothesis for explaining this result is that domain-specific traces are designed to only contain the evolution of dynamic objects with minimal redundancy and, hence, consume less memory than clone-based ones that contain significant redundancy. To summarize and answer RQ2, we observe that domainspecific traces are more efficient in memory than generic and clone-based traces. Moreover, customized domain-specific traces reduce even more significantly the memory consumption for a specific application context. The trace analysis defined on traces conforming to the generic and clone-based trace metamodel comprises 109 lines of code distributed in 15 operations defining 62 statements in total. Five loops are required for traversing the states captured in the traces, as well as the quite complex data structure of the execution metamodel of fUML.
Acknowledgements Open access funding provided by  TU Wien  This work is supported the  INS GEMOC  ( ANR-12-INSE-0011 ), the  COST Action   MPM4CPS  ( IC1404 ), the  Christian Doppler Forschungsgesellschaft CDL-Flex , the  BMWFW , the  Austrian Science Fund (FWF) :  P 28519-N31 , the  Austrian Agency for Cooperation in Education and Research (OeAD)  under the grand number  FR 08/2017  and by the  French Ministries of Foreign Affairs and International Development (MAEDI)  and the  French Ministry of Education, Higher Education and Research (MENESR).
Number of static metaclasses, DC. Number of dynamic metaclasses, DP. sion, our semantic model differencing framework utilizes a generic and clone-based trace metamodel for represent-ing execution traces. More precisely, a trace conforming to this metamodel is a sequence of clones of the executed model that capture the model's execution states after each Number of step rules, state change. Number of dynamic properties. SR. Number of properties in the generated trace metamodel TMM Generated trace metamodel, TMM C. Number of metaclasses in the generated trace metamodel, TMM P. a https://github. com/moliz/moliz. gemoc/tree/master/examples/petrinet/language_workbench.
b https://github. com/moliz/moliz. gemoc/tree/master/examples/petrinet/language_workbench/org. modelexecution. xmof. examples. petrinet. trace/model/petrinetConfigurationTrace. ecore c https://github. com/moliz/moliz. gemoc/tree/master/examples/fuml/language_workbench d https://github. com/moliz/moliz. gemoc/tree/master/examples/fuml/language_workbench/org. modelexecution. xmof. examples. fuml. trace/model/fumlConfigurationTrace. ecore e https://github. com/gemoc/arduinomodeling/tree/master/dev/language_workbench_sequential f https://github. com/gemoc/arduinomodeling/tree/master/dev/language_workbench_sequential/org. gemoc. arduino. sequential. xarduino. trace/model/arduinoTrace. ecore g https://github. com/gemoc/gemoc-studio/tree/master/official_samples/TFSM_PlainK3/language_workbench h https://github.
com/gemoc/gemoc-studio/tree/master/official_samples/TFSM_PlainK3/language_workbench/org. gemoc. sample. tfsm. sequential. xtfsm. trace/model/tfsmTrace. ecore i https://github. com/moliz/moliz. gemoc/tree/master/examples/iml/language_workbench j https://github. com/moliz/moliz. gemoc/tree/master/examples/iml/language_workbench/org. modelexecution. xmof. examples. iml. sequential. sequentialiml. trace/model/imlTrace. ecore k https://github. com/tetrabox/minitl/tree/master l https://github. com/tetrabox/minitl/tree/master/plugins/org. tetrabox. example. minitl. trace/model/minitlTrace. ecore m https://github. com/gemoc/activitydiagram/tree/master/dev/gemoc_sequential/language_workbench n https://github. com/gemoc/activitydiagram/tree/master/dev/gemoc_sequential/language_workbench/org. gemoc. activitydiagram.
FRAMA-C is a software analysis framework that provides a common infrastructure and a common behavioral specification language to plugins that implement various static and dynamic analyses of C programs. Most plugins do not support concurrency. We have proposed CONC2SEQ, a FRAMA-C plugin based on program transformation, capable to leverage the existing huge code base of plugins and to handle concurrent C programs. In this paper we formalize and sketch the proof of correctness of the program transformation principle behind CONC2SEQ, and present an effort towards the full mechanization of both the formalization and proofs with the proof assistant COQ.
Introduction FRAMA-C  [10, 9]  is a framework for static and dynamic analysis of C programs. It offers a common infrastructure shared by various plugins that implement specific analyses, as well as a behavioral specification language named ACSL  [2]. Developing such a platform is a difficult and time-consuming task. As most existing FRAMA-C plugins do not support concurrent C code, extending the current platform to handle it is an interesting and promising work direction. Motivated by an earlier case study on deductive verification of an operating system component  [3] , we have proposed a new plugin, named CONC2SEQ  [4] , that allows FRAMA-C to deal with concurrent programs. In order to leverage the existing plugins, we designed CONC2SEQ as a code transformation tool. For sequentially consistent programs  [12] , a concurrent program can be simulated by a sequential program that produces all interleavings of its threads.
To ensure that the proofs and analyses conducted using CONC2SEQ are correct, we need to assure that the transformation preserves the semantics of programs. The contribution of this paper presents the proof of correctness of the code transformation principle used in CONC2SEQ. The verification of the transformation is done for simplified languages that capture the interesting property with respect to validity, in particular memory accesses and basic data and control structures (both sequential and parallel). We formalize the source (parallel) language as well as the target (sequential) language and formally define the transformation on these languages. In these languages, we do not consider all control structures of the C language but only simple conditionals and loops (goto and switch are not part of the considered languages).
procs prog denotes the sequence of procedures of the program. For a parallel program mains prog is the mapping from T to Name, and for a sequential program main prog is the main procedure name. For a name m and a program prog, body prog (m) denotes the body of the procedure named m in the program prog. If it is clear from the context prog may be omitted. Comparison with the concurrent C of the FRAMA-C plugin. For sequential programs, the simplifications with respect to the subset of C handled by our CONC2SEQ plugin are essentially that we do not support pointer arithmetic, the expressions containing several memory reads or procedure calls should be decomposed, and we support only the "most structured" control structures. The typing is also very basic: variables and heap locations accept any type of values (integers, booleans, memory locations) and the type of expressions is checked dynamically by the semantic rules if necessary (for example the expression that is a condition of a loop or conditional should evaluate to a boolean value).
Finally, we initialize terminated to false, since each thread must, at least, return from its main, ensuring the  (5). We have reached a state σ 0 sim equivalent to stacks init , η init par. Lemma 2 (Forward simulation on a single step). Let prog par be a safe parallel program and prog sim its simulating program, σ par a parallel state that reaches σ ′ par with an event (t, a par ), σ sim equivalent to σ par , there exists a trace tr equivalent to [(t, a par )] that allows to reach σ ′ sim equivalent to σ ′ par. Sketch of proof. By the equivalence relation, we know that σ sim is of the form: ((. , ρ sim , while ¬terminated do (c select + + c sim + + c termination )), η sim ) In the parallel semantics, we perform a step of reduction for the thread t, so its stack is not empty, and by (3a), we know that η sim sim [t](pct) = 0, and consequently, by (  5 ), ρ sim (terminated) = false.