The challenges in implementing SAE Level 4/5 automated vehicles are manifold, with intersection navigation being a pervasive one. We analyze a novel road topology invented by a co-author of this paper, Xiayong Hu. The topology eliminates the need for traditional traffic control and cross-traffic at intersections, potentially improving the safety of autonomous driving systems. The topology, herein called the Zonal Road Topology, consists of unidirectional loops of road with traffic flowing either clockwise or counter-clockwise. Adjacent loops are directionally aligned with one another, allowing vehicles to transfer from one loop to another through a simple lane change. To evaluate the Zonal Road Topology, a one km2pilot-track near Changshu, China is currently being set aside for testing. In parallel, traffic simulations are being performed. To this end, we conduct a simulation-based comparison between the Zonal Road Topology and a traditional road topology for a generic Electric Vehicle (EV) using the Simulation for Urban MObility (SUMO) platform and MATLAB/Simulink. We analyze the topologies in terms of their travel efficiency, safety, energy usage, and capacity. Drive time, number of halts, progress rate, and other metrics are analyzed across varied traffic levels to investigate the advantages and disadvantages of the Zonal Road Topology. Our results indicate that vehicles on the Zonal Road Topology have a lower, more consistent drive time, make more progress, and halt less frequently, while using less energy on average. The Zonal Road Topology also has the capacity to support a greater amount of vehicles. These results become more prominent at higher traffic densities.

Simulation-based software testing supports engineers in finding faults in Simulink®models. It typically relies on search algorithms that iteratively generate test inputs used to exercise models in simulation to detect design errors. While simulation-based software testing techniques are effective in many practical scenarios, they are typically not fully integrated within the Simulink environment and require additional manual effort. Many techniques require engineers to specify requirements using logical languages that are neither intuitive nor fully supported by Simulink, thereby limiting their adoption in industry. This work presentsHECATE, a testing approach for Simulink models using Test Sequence and Test Assessment blocks from Simulink®Test™. Unlike existing testing techniques,HECATEuses information from Simulink models to guide the search-based exploration. Specifically,HECATErelies on information provided by the Test Sequence and Test Assessment blocks to guide the search procedure. Across a benchmark of$18$Simulink models from different domains and industries, our comparison ofHECATEwith the state-of-the-art testing toolS-Taliroindicates thatHECATEis both more effective (more failure-revealing test cases) and efficient (less iterations and computational time) thanS-Talirofor$\approx$94% and$\approx$83% of benchmark models respectively. Furthermore,HECATEsuccessfully generated a failure-revealing test case for a representative case study from the automotive domain demonstrating its practical usefulness.

Automotive software development requires engineers to test their systems to detect violations of both functional and drivability requirements. Functional requirements define the functionality of the automotive software. Drivability requirements refer to the driver's perception of the interactions with the vehicle; for example, they typically require limiting the acceleration and jerk perceived by the driver within given thresholds. While functional requirements are extensively considered by the research literature, drivability requirements garner less attention. This industrial paper describes our experience assessing the usefulness of an automated search-based software testing (SBST) framework in generating failure-revealing test cases for functional and drivability requirements. We report on our experience with the VI-CarRealTime simulator, an industrial virtual modeling and simulation environment widely used in the automotive domain. We designed a Cruise Control system in Simulink for a four-wheel vehicle, in an iterative fashion, by producing 21 model versions. We used the SBST framework for each version of the model to search for failure-revealing test cases revealing requirement violations. Our results show that the SBST framework successfully identified a failure-revealing test case for 66.7% of our model versions, requiring, on average, 245.9s and 3.8 iterations. We present lessons learned, reflect on the generality of our results, and discuss how our results improve the state of practice.

Awareness of the importance of systems and software traceability, as well as tool support for traceability, have improved over the years. But an effective solution for traceability must align and integrate with an organization’s engineering processes. Specifically, the phases of the traceability process model (traceability strategy, creation, use and maintenance of traceability) must be aligned with the organization’s engineering processes. Previous research has discussed the benefits of integrating traceability into the configuration management process. In this paper, we propose Change Request management using traceability data. In our approach, new Change Requests (CRs) are created from the traceability model of the corresponding project. The created CRs contain a portion of the project’s overall traceability model that is relevant to that change. A proof-of-concept issue tracking system is proposed that uses a traceability model at its core.

Model-Based Development (MBD) is widely used for embedded controls development, with MATLAB/Simulink being one of the most used environments in the automotive industry. Simulink models are the primary design artifact and as with all software, must be constantly maintained and evolved over their lifetime. It is necessary to develop models that support likely changes in order to assist with evolution/maintenance processes. In order to do so, the types of frequently performed changes must be understood and appropriate language mechanisms must be available to support these changes. However, Simulink model changes are currently not well understood. We analyze a real industrial software repository of our industrial partner and its version control system to provide insights into the likely changes for Simulink. The intent with this analysis includes providing guidance on how Simulink is used in industrial practice and how particular model changes can impact system evolution.

This paper presents and evaluates the Boundary Diagram Tool for change impact analysis of large Simulink designs of embedded systems. In our previous work, we developed the Reach/Coreach Tool for model slicing within a single Simulink model. The current work extends the Reach/Coreach Tool to trace the impact of model changes through multiple models comprising an embedded system, including network interfaces. The change impact analysis results are represented using various diagrams motivated by industrial needs. Several techniques are used to improve understanding of impact analyses of large industrial systems. The tool has been integrated into the software development process of a large automotive OEM (Original Equipment Manufacturer) to support the following activities: change request analysis and evaluation, implementation, verification and integration. The tool also aids impact analyses required for compliance with functional safety standards. The tool’s effectiveness has been demonstrated on production-scale models.

In the Matlab Simulink environment, systems can be modelled using Simulink block diagrams and Stateflow state charts. While stateful logic is more naturally modelled using Stateflow, in practice complex block diagrams are often used instead, resulting in models that are hard to understand and maintain. In order to improve the maintainability and understandability of large industrial models, this paper presents a strategy for refactoring Simulink block diagrams implementing stateful logic into functionally equivalent Stateflow state charts that more naturally represent the intended behaviour. To bridge the gap between the syntax of block diagrams and state charts, Mealy machines represented by tabular expressions are used as an intermediate representation. The compositional language of block diagrams is used to combine tables modelling individual blocks into a table for the entire block diagram which describes the high level state machine encoded in the Simulink subsystem. A prototype tool that performs the translation from Simulink to Stateflow automatically is discussed.

In this paper we draw on our experience in the automotive industry to portray the clear need for proper documentation of Simulink models when they describe the implementations of embedded systems. We effectively discredit the “model is documentation” motto that has been hounding the model-based paradigm of software development. The state of the art of documentation of Simulink designs of embedded systems, both in academia and industrial practice, is reviewed. We posit that lack of proper documentation is costing industry dearly, and propose that a significant change in development culture is needed to properly position documentation within the software development process. Further, we discuss what is required to foster such a culture.

Abstract: This paper presents a set of tools that provide automatic support for application of some of the traditional soft-ware engineering practices when developing with Simulink. The tools are the: Signature Tool, Reach/Coreach Tool, Data Store Push-Down Tool, and Auto Layout Tool. The Signature Tool extracts the interface of a Simulink subsystem, identifying the subsystem’s explicit, and implicit data flow mechanisms, empowering developers to use the implicit mechanisms more effectively. The Reach/Coreach Tool identifies data and control flow dependencies in a Simulink model and uses the information for model slicing. The view of de-pendencies offered by the tool significantly eases the comprehension of large models. The dependencies can also serve as indicators of alternative designs, and facilitate more effective testing and verification. The Data Store Push-Down Tool restricts the scope of Simulink’s data stores thereby providing improved encapsulation, and increasing modularity. Finally, the Auto Layout Tool significantly decreases the manual effort develop-ers spend in achieving proper layout of models during design and refactoring, and can be used by automated refactoring and transformation tools. 1

Model comprehension and effective use and reuse of complex subsystems are problems currently encountered in the automotive industry. To address these problems we present a technique for extracting, presenting and making use of signatures for Simulink subsystems. The signature of a subsystem is defined to be a generalization of its interface, including the subsystem's explicit ports, locally defined and inherited data stores, and scoped gotos/froms. We argue that the use of signatures has significant benefits for model comprehension and subsystem testing, and show how the incorporation of signatures into existing Simulink models is practical and useful by discussing various usage scenarios.