Software Engineering Practices And Simulink: Bridging The

Software engineering practices and Simulink.destination and source block are listed, as well as thetotal number of moved data stores in the model. Also,this paper demonstrates the application of the tool in thedetection of data stores that are declared, but unused.– When it comes to the Reach/Coreach Tool, the commonassumption for If/Switch Case blocks that all inputsaffect all outputs has now been removed. Consequently,the tool has been enhanced to identify the fine-graineddependencies between the blocks’ inputs and outputs.While the improvement is conceptually rather simple, ithas been shown to provide some subtle static analysis ofreal-world industrial models, as will be illustrated in thispaper. Furthermore, the Reach/Coreach Tool is shownto provide an additional data view whose application isdemonstrated when the tool is used as an impact analysis tool. Also, starting from Matlab R2015a, SimulinkDesign Verifier, a MathWorks’ Matlab/Simulink toolbox,includes Model Slicer which has capabilities similar tothose of the Reach/Coreach Tool. In this paper, we presenta detailed comparison between the capabilities of theReach/Coreach Tool and Model Slicer.– The Auto Layout Tool has been significantly extended.Firstly, it now supports a number of minor, yet verypractical transformations: transforming a From/Gotoconnection to a signal connection (and back), as wellas flattening of a model’s hierarchy. Secondly, the layoutengine itself has been significantly enhanced to increasemodel readability, while following some of the best practices for layout of Simulink models as prescribed by theMAAB guidelines [28].Also, it is worth noting that all four tools have been significantly improved in terms of usability. While they were initially Matlab command line functions, they are now invokeddirectly from the context menu. Furthermore, the SignatureTool and the Reach/Coreach Tool now feature simple graphical user interfaces. All the tools are available through MatlabCentral, under open-source licenses [1,5,16,19].All the tools have been successfully used on large industrial automotive models: the models contained between 3671and 73044 blocks, with hierarchy depths between 8 and 16.However, for simplicity of exposition, smaller examples havebeen chosen in this paper to illustrate the tools’ capabilities.The outline of this paper is as follows. Section 2 analysesdata flow in Simulink and presents an industrial model thatwill be used throughout the paper to demonstrate the application of the tools in an industrial setting. The Signature Tool,the Reach/Coreach Tool, the Data Store Rescope Tool, andthe Auto Layout Tool are presented in Sects. 3.1, 3.2, 3.3,and 3.4, respectively. For each of these tools, we explain andillustrate their main capabilities, implementation, and possible applications in model-based design with Simulink. Wealso present the execution times of the tools when run onvarious real-world industrial automotive models. The toolswere run on a Windows 7, Intel i3-2120 @ 3.30 GHz, 8.0 GBRAM machine. Section 4 summarizes the role of the tools inmodel-based development processes and their link with software engineering principles. Section 5 concludes the paper,with avenues for future work.2 Data flow in Simulink and exampleThis section first presents an analysis of data flow inSimulink, which will serve as the necessary backgroundknowledge for a reader to understand the tools’ capabilitiespresented in Sect. 3. Afterward, a real-world industrial modelis presented. This model will be used throughout the paper toillustrate the applicability of our tools in an industrial setting.2.1 Analysis of data flow in SimulinkThe notion of a subsystem is used in Simulink to represent systems inside systems in order to provide hierarchicalmodeling. A Simulink subsystem has inports and outports—explicit links to and from the subsystem, respectively. Weview inports and outports as the explicit interface of thesubsystem. However, there are hidden data dependencies inthe Simulink’s subsystem: we will refer to those as the subsystem’s implicit interface. Hidden dependencies stem fromtwo particular Simulink data mechanisms: data stores andGoto/From blocks.Data stores Data stores are used in Simulink as memoryand are analogous to variables in traditional programminglanguages. Data stores allow subsystems and referencedmodels2 to share data without having to use inports and outports to pass the data from subsystem to subsystem, or levelto level. A data store can be defined in Simulink using a DataStore Memory block. The data store is then referenced usingData Store Read blocks (for reading from the data store) orData Store Write blocks (for writing into the data store). Thescope of a data store is the subsystem where the Data StoreMemory block is located, and all the subsystems below it inthe model hierarchy, excluding referenced models. In Fig. 1,data store B is defined using Data Store Memory B block.The scope of this data store is the top level of the model andsubsystem Sub1. The data store is accessed using Data StoreWrite B at the same level where it is defined, and it is readusing Data Store Read B in subsystem Sub1 (the contents ofsubsystem Sub1 are shown in Fig. 2). Also, a data store canbe implemented in the base workspace using a signal object:it is then called a global data store as it can be accessedfrom anywhere in the model, including referenced models.2A referenced model is a model referenced from another model usinga Model block.123

V. Pantelic et al.ABData StoreMemory AData StoreMemory {Scoped1}Goto1zBUnit DelayData StoreWrite B{Scoped1}Goto TagVisibilityFig. 1 A Simulink modelnon-virtual subsystems as well. Non-virtual subsystems aresubsystems executed as a single unit (atomic execution). Avirtual subsystem, on the other hand, is flattened in order toderive the block update order, with Simulink ignoring thesubsystem’s boundaries when determining this order. That isto say, the subsystem’s boundaries do not impact the model’sbehavior.Goto/From mechanism Another mechanism for implicitdata flow in Simulink is the Goto/From mechanism. Thedata fed into a Goto block is passed to its correspondingFrom blocks (the From blocks with the same tag), without a signal line between them. Goto/From blocks are usedto implicitly connect blocks, simplifying the visual presentation of models. A single Goto block may have multipleFrom blocks, but a From block may only receive data froma single Goto block. The scope of the Goto block is determined by the Goto block’s Tag Visibility parameter, whichcan take on the following values:– Local: Goto and From blocks with the same tag are inthe same subsystem.– Scoped: The scope of the Goto block is determined bythe position of the corresponding Goto Tag Visibilityblock. The Goto block and its From blocks have to bein the same subsystem as the Goto Tag Visibility blockor lower in the model hierarchy, while not crossing anon-virtual subsystem boundary, i.e., the boundary of anatomic, conditionally executed or function-call subsystem, or a model reference. In Fig. 1, scoped tag Scoped1is defined using a Goto Tag Visibility block. This blockaffects the scope of the Goto block Scoped1, found to itsimmediate left at the same level, while the correspondingFrom is found in Sub1, as shown in Fig. 2.– Global: Goto and From blocks with the same tag canbe anywhere in the model, except in locations that spannon-virtual subsystem boundaries.2.2 Industrial exampleFig. 2 Subsystem Sub1 from Fig. 1There may also be multiple read and write blocks for a singleData Store Memory block within one simulation step. Thisintroduces issues with the order of access to a data store (foran explanation of order of access errors and correspondingMatlab’s diagnostics, an interested reader is referred to [25]).When a data store is located higher in the hierarchy thanthe current subsystem, it will be referred to as an inheriteddata store for the subsystem. It should be noted that whilesignatures have previously been defined only for virtual subsystems [2], the current implementation of the SignatureTool is extended to support the extraction of signatures of123This section introduces the obfuscated version of the industrial model that will be used as a running example in thispaper. The original model was obfuscated for confidentialitypurposes. The model is a subsystem of a larger model thatitself implements a portion of the gear selection functionalityin a hybrid electric vehicle. The model is shown in Fig. 3a–h.3 ToolsThis section presents the tools. For each tool, its basiccapabilities are presented in detail and illustrated on a toyexample. Afterward, the application of the tools is demonstrated on the industrial model. Using both the simple toy

Software engineering practices and Simulink.(a)(b)(c)(d)(f )(e)(g)Fig. 3 Industrial example Simulink model. a Subsystem Gear andMode Processing performing gear selection. b Subsystem Gear Processing from a. c Subsystem If Gear1 from b. d Subsystem If Gear2(h)from b. e Subsystem If Gear345 or Else from b. f Subsystem CurrentEntry from c. g Subsystem Current Entry from d. h Subsystem CurrentEntry from e123

V. Pantelic et al.model and the industrial model enables us to first show thebasic capabilities of the tools in a simple manner, and thenshowcase their applicability and practicality on a real-worldindustrial automotive model.3.1 The Signature ToolThe Signature Tool extracts the signature of a Simulink subsystem. The concept of signatures was first introduced in [2].A signature represents the interface of a Simulink subsystemby making all of the data flow into and out of the subsystemexplicit.Further building on this work, we now view globalFrom/Gotos and global data stores as special cases of scopedFrom/Gotos and data stores. This is due to the fact that globaltags can be replaced by scoped tags, with a corresponding visibility tag placed in the top-level subsystem. Likewise, globaldata stores can be replaced by normal data stores, with thecorresponding declaration moved to the top-level subsystem.3.1.1 SignatureThe signature identifies the elements of the interface for agiven Simulink subsystem:– Explicit interface: Inports and outports,– Implicit interface: Inherited data stores, and scoped tagsdefined higher up in the model hierarchy,– Imposed interface: Data stores and scoped tags definedin the subsystemThe Signature Tool identifies two useful signatures for asubsystem: the strong signature and the weak signature. Ingeneral, the strong signature identifies the data mechanismsthat are accessed by the subsystem or any of its children.The weak signature identifies the data mechanisms that asubsystem can access (those which are declared locally orhigher up in the hierarchy), but is not necessarily using. Notethat the question of whether or not these are in fact accessedduring the execution of a model is difficult, and requires deepanalysis of con

Simulink, neither do we compare the model-based design of Simulink to more traditional development paradigms. Rather, we draw on our experience from working with production-scale Simulink models to suggest mechanisms and appropriate tool support to improve the application of some well-known