System Definition =================== The definition of the system allows to perform a simulation of the entire system taking into consideration the interactions among runnables, ECUs and messages on the network. During the simulation it is possible to check a set of timing constraints to validate the functionality of the overall system. The platform allows to create multiple **scenarios** to track the evolution of the architecture, and simulate different use cases that would be very expensive to test on the real hardware architecture. Scenarios can be created from scratch, or evolve from an another scenario and allow to: * define the overall architecture by means of **ECU types** (defined in the ECU Types section) and **communication channels** (i.e. CAN network with specific bandwidth) * specify data for each specific **network** * define the **software components** available in the system * insert a set of **timing constraints** to be validated during the simulation * define multiple tasks and **task mappings** to be simulated Scenarios are pretty powerful, as they allow to test, in a digital environment, your system under different conditions. As an example, it is possible to simulate the current situation of the architecture to check for timing issues, check the impact of the addition of a new piece of software into an existing architecture, or simulate the behavior of the software with a different set of tasks, or mapping of tasks on the different cores of a single ECU or on a different ECU. ECUs -------- .. image:: img/ecus.png :height: 350 :alt: The result of the definition of ECUs and networks ECUs section allows to create a digital representation of the ECUs available in your architecture, and how they interconnect with specific networks. In this section it is possible to instantiate multiple ECUs, starting from the :ref:`ECU Types<1. ECU Types>` defined in the specific section. For each instantiation, it is possible to define: * a name for the ECU Type instance * the type of the of the ECU as in the :ref:`specific section<1. ECU Types>` * a cost for the ECU - this is useful to obtain a total cost for the simulated solution * the network interfaces of the ECU. For each interface it is possible to define a name, and the type of interface. .. image:: img/ecu.png :height: 300 :alt: A defined ECU with its network interfaces Above you can find how it looks like an ECU called PCDC, that implements an ECU Type that we have defined as TC397 and contains 4 network interfaces of type CAN. Network Data --------------- To obtain a detailed simulation of the system, that includes an analysis of the traffic on specific networks, it is possible to specify the **Network Frames** of each specific network, defined in the :ref:`ECUs` section. A Network Frame is defined by: * Name * Period * Size of Payload * Network on which it passes * [optional] Identifier * [optional] wether it uses or not the extended format The platform will simulate the traffic on the network based on the information provided in this section, that can be defined manually, or automatically, uploading a specific **DBC** file. The information inserted in this section, can be also used to analyze the network as a standalone element, by using the :ref:`Network Analysis functionality` Software Components -------------------- This section hosts the information regarding the software available in the scenario. Software is defined by: * **Software Components** that can be composed by one or more runnables (or step functions) * communication **interfaces** Software Components contain information about runnables (or step functions), and for each runnable: * **Assigned Ports** identified by the name, the type of access (i.e. read/write), port type (i.e. provide/require) and the relative interface. * **Events** that identify how the function is called (i.e. periodically with a specific period) * **Operation Modes** that define when the runnable is active during the simulation/execution (see :ref:`section on Operation Modes`) Each element defined in this section, can be univocally identified by two elements, the **UUID** and the **Entity Reference**. Both this information are used by the platform to identify the component, and to understand the connections among different components. The manual modification of an entity reference, may cause the platform to lose track of a relationship between a runnable and a specific port. For more information on how UUID and Entity Reference are used please see the section :ref:`Consideration on UUID and Entity Reference` The population of this specific section can be time consuming, and evolves while software is being developed. For this reason, we offer three methodologies to populate it: 1. specifying one, or more, ARXML files 2. using the "SWCs from Hprofs" button 3. manually If compliant with the **Autosar** specification, it is possible to directly specify the ARXMLs containing the information of the Software Component, and the platform will automatically populate all the data, keeping the relationships among elements defined with UUIDs and Entity References. The platform will also check for the consistency of the data provided by the ARXML, so that it is possible to identify accidental error or manual modification to the ARXML. In case the ARXML is not available, it is possible to use the **SWCs from Hprofs** button. This button fetches the information on the Software Components directly from the HPROF uploaded in the :ref:`Runnable Performance` section. Note that this data could be incomplete, depending on the information stored in the HPROF upon generation. Operation Modes ################ Operation Modes allow to simulate specific use cases of the system (i.e. key turn). In this section it is possible to define a set of **states** in which the system could be, and the relatives runnables' state for the specific system state. Once a set of states is defined, it is possible to define the activation or deactivation of a specific state in the :ref:`Simulation Schedule` Timing Constraints -------------------- While the simulation itself provides information regarding performance (i.e. execution time) and resource occupancy, it is possible to place additional checks related to timing and interactions of runnables/functions and messages passing on the networks. It is possible to define two categories of timing constraints: 1. Timing event chains 2. Order constraints **Timing event chains** allows the definition of a maximum time budget for a specific set of events, for which it has been defined an order of execution. The event is defined either by an operation on a runnable/function, such as start/end, or by an operation on a network frame, such as its start, end or when it became ready. .. image:: img/eventchaindef.png :height: 430 :alt: The definition of an event chain in the platform In the example above, it is shown how to define an event chain that involves both runnable/functions and messages on specific buses with a maximum time budget defined of 15ms. When a simulation is launched, the system will automatically add this check in the analysis, and will raise an error in case there is one or more instances of this event chain that is failing. With the platform is easy to relocate runnables/functions or messages on different ECUs or networks. To this end, the "Exclude if same ECU" flag permit to avoid to communication on the network in case the two runnables/functions that produce/consume the message are located in the same ECU. Event chains are pretty powerful as can be used in multiple scenarios. They can be used to monitor specific runnable/function-message interaction, or to check the periodicity of specific runnables. In general, thanks to event chains it is possible to monitor any interaction between events that need to happen within a time budget. The second type of timing constraints is represented by **order constraints**. These constraints allow to define the expected order of execution of runnables within tasks. This constraint is not evaluated during simulation, but rather during task mapping, and will not be considered for runnables/functions mapped to different tasks.\ The modal accepts an ordered list of runnables/functions and permits the definition of two flags. The first one checks for a strict ordering, validating that no runnable/function is executed between the defined order; the second one validates that the runnables/functions execute on the same task. Task Mapping -------------- The section allows the creation of multiple task mappings and, as for the scenario, it is possible to copy and evolve the configuration of a specific task mapping. For each specific mapping it is possible to define: * Tasks * mapping of runnable/function to tasks * mapping of task to ECU and core of the ECU Tasks are identified by a name, an optional UUID and the Entity Reference that is automatically generated when task is manually created. For each task it is necessary to provide the trigger (i.e. a periodic task with its specific period), the mapping of the task on a core of a specific ECU, its priority and preemptability. For each task then, the system automatically filters runnables/functions with a compliant period that could be mapped to it. At this stage, the system automatically checks the :ref:`order constraints` defined in the dedicated section. As for other sections of the platform, there are three ways to perform a task mapping: * Providing the Os, Rte and EcuC ARXML files * Using the **automatic mapper** * manually Define a mapping using the Automatic Mapper ################################################# The automatic mapper is a utility that performs a design space exploration (DSE) to suggest a possible solution to the mapping problem. The output of the utility is a suggestion of mapping of periodic tasks and runnables/functions on the target architecture. .. image:: img/mappingopt.png :height: 430 :alt: The launch of a mapping optimization It is possible to launch the mapping optimizer either on an empty mapping (i.e. no tasks have been defined yet), or with an intermediate/full set of tasks defined. It is possible to define multiple degrees of freedom to allow the mapping optimizer to: * permit the creation of new periodic tasks * allow the mapping of unmapped periodic tasks on ECU cores * allow the mapping of unmapped periodic runnables on ECU cores * define the cores on which the automatic mapper is allowed to operate In case tasks are already defined in the mapping, it is possible, with task-granularity, to avoid changes by the automatic mapper to: * task mapping * preemptability * priority * runnables mapped to the task In its default configuration, the automatic mapping optimizer will have the capacity to create new periodic tasks, choose a specific mapping, preemptability, priority and set of periodic runnables to map onto it. The automatic mapping optimizer will apply a strategy to minimize resource occupancy while avoiding runnables/functions execution overlap. The final result of the automatic mapping optimizer, will be a mapping proposal, that needs to be accepted or refused by the user. The report will highlight the main modification with current mapping to highlight differences. The utility is pretty useful, especially when evaluating a different architecture with respect to the one defined at the beginning, and a task mapping has not been defined yet; or to optimize an existing mapping. UUID and Entity Rerefence --------------------------- UUIDs and Entity References are used to univocally identify resources in a project. Thanks to this relationship, the platform is able to track the evolution of the single components, and to correctly simulate the interaction among different components (i.e. two runnables and their respective ports during a timing simulation). It can happen however, that this references are modified during the development stages. In this case, the platform has in place some checks to make sure that components are not defined multiple times, but with different ids. It is always up to the developer, to make sure that the references are constantly updated, so that the simulation can be as precise as possible.