Team: VCE/AVL + DT + solutions providers

Challenge: FMU continued

Context

• The challenge is a continuation of ongoing activities from previous hackathons between VCE/AVL and solution providers.
  In this particular challenge, we consider a battery in an electric vehicle and the corresponding TMS. When designing such a system it is of interest to understand what might be viable configurations of a system based on commonly used components when used in various scenarios. In this regard, it is useful to perform simulation to understand the viability of the system when considering different types of components.

Goals

• The general goal can be defined as Defining architecture in SysML and then instantiating simulations from these definitions. SysML model corresponds to a model version of the considered system, in this case, a battery and TMS. IBD considers an instantiated IBD from the SysML model by taking into account the context of the system. Simulation refers to the execution of one or more FMU instantiated from the SysML model. Optimization refers to a (most likely iterative) process to parameterize the elements of the SysML/Simulation model to find a suitable set of parameters for the considered system. The last step is then to finally create the architecture in an IBD format in SysML annotated with the parameters obtained through the optimization.
  

Team: PRO + ITI + ACO + UOC

Challenge: Monitoring and modelling a SPMP (continued)

Context

• The generic objective is to implement a monitoring system of all the elements of a Smart Port Monitoring Platform (SPMP) to detect the problems that may happen as soon as possible and in an automatic way and also, to model the entire infrastructure to anticipate future problems due to the overload or lack of resources.As in previous hackathons, the main aim in this hackathon is to tackle solutions for an updated set of key sub-challenges listed in the following section). These solutions are expected to boost the collaborations held by the SPMP team, extended and stabilised after the previous hackathon in Valencia.

Goals

• Model and implement quality of service business rules regarding the integrity and other factors characterising the data collected and transferred from the port sensors.
• Progress on the Edge Monitoring and Analysis Infrastructure.
• It is also expected that UOC supports ACO in the production of a generic data model for the GAA results
• Development of various performance metrics for the smart port (or smart city) distributed architecture.
• Experimental investigation of several different constrained multi-objective optimisation algorithms for allocation of software microservices to processing nodes.
• Development of a simulator for monitoring and prediction of the expected processing demands under various different environmental conditions (e.g. number of ships waiting for loading or unloading)

Team: Westermo and Copado

Challenge: Performance data exploration

Context

• Automotive Grade Linux (AGL) is an open-source operating system for automotive applications. The AGL project is trying to create a standard for in-vehicle software solutions by bringing together car manufacturers, suppliers, and software companies. Despite the fact that AGL is still very much in development, the first distributions are already available. To be part of this standardisation process, it is critical to ensure the reliability and security of such systems from the very beginning.
  

Goals

• The goal of this challenge is to explore the performance data, and see what one could learn. One idea is to be inspired by the final thesis of Sara Salahshour Torshizi (2022): Software Performance Anomaly Detection Through Analysis Of Test Data By Multivariate Techniques. Master's thesis, Uppsala University, Sweden. Online: http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-480514 External link.

Team: ABI+UNISS

Challenge: Modeling properties constraints of the Abinsula Use Case – Update

Context

• Modern cars are connected systems and acquire inputs from the environment; thus, they can be considered as Cyber-Physical Systems. In this case study the sensors are the cameras that are meant to replace the rear-view mirror. The system is expected to autonomously react according to external stimuli and internal needs. In such a context, new challenges in the development process are arising. This is especially true where several stakeholders, such as hardware specialists, software developers and system designers have to work together with safety engineers to ensure a reliable and safe system.

Goals

• The long-term goal is to formally verify, at the design stage, the consistency of the system design with respect to some given property constraints, with the purpose to reduce inconsistencies during the system development process. We intend to leverage on models at higher levels of abstraction which are able to capture systems’ properties. These models can then be used to check system-level properties or to explore alternative architectural solutions for the same set of requirements.
  

Team:ALSTOM + MDU + AVL + ABO

Challenge: Automatic parametrization of PS controllersstem

Context

• At Alstom, the parametrization of the propulsion system controller is performed by a control engineer through exhaustive tuning experiments in a dedicated lab. In these experiments, the control engineer runs the system under predefined operational conditions and tunes the controller parameters accordingly. With the development of digital tools, operational data can be collected and used later to tune the models’ parameters. Nevertheless, tuning the model’s parameters from operational data collected from different driving cycles is challenging, as the model has to capture the underlying behaviour from all driving cycles’ data.
  

Goals

• We aim to develop AI tools to automatically parametrize the propulsion system controller. More specifically, the AI tools will estimate the models’ parameters from operational data collected during different driving cycles.

Team: ROTECH -+TEK

Challenge: Requirements analysis, processing and response

Context

• Services in an environment partly simulated.
• Measured data collected and pre-processed (cleaning, filtering, features extraction) to obtain “monitoring data”.
• Data transferred to the remote computing and data storage aggregator whose resources are available to run a full capabilities PHM system.
  

Goals

• Bridger: provides the communication between the On-board Platform and Remote Platform. It introduces the features of secure communication using an encryption and decryption algorithm.

• Data Aggregator: Provides to help them make better decisions, improve process efficiency and finally, understand performance of the Platform. Consistent evolution, and the usability of the data plays a vital role too.

Team: TEK+AST

Challenge: Runtime Verification

Context

• The scenario TEK_UCS_02 “Run-time verification” is related to software testing. TEK searches for a solution that, in a semi-automatic way, is capable of defining and executing the tests, as well as interpreting the tests results.
  

Goals

• TEK use case scenario requires automatic generation of test code. The AST tool, devmate, uses technologies for equivalence-based testing, to produce a test model from which we can generate test code.To satisfy TEK use case scenario, devmate needed support for the C language. Hence, AST’s first tasks were to develop a parser for the C language and to adapt the user interface for C specific features. A code generator was developed that produces test code in C++, executable with Google Test.
• The tool devmate can be used in two ways:
  • It can be used to define test data and expected output based on the requirements of the user and therefore the generated code is an automated code for the validation of the implemented function under test (check if the function works as intended).
  • The generated test code can further be used in case of refactoring for the verification of the function under test (after refactoring the function works in the same way furthermore).

Team: AVL + AIT

Challenge: Parameter space reduction in TCV USE CASE

Context

• Since Hardware-in-the-loop (HIL) or vehicle test execution is very expensive, and the possible parameter space for generating ADAS/AV test cases is in general huge, we want to reduce the parameter space effectively prior to sampling such that non-critical/not interesting cases are excluded. The challenge is to look at a more generalized problem definition potentially involving more complex scenarios including non-linear trajectories and further physical parameters of the road users. The challenge is to look at a more generalized problem definition potentially involving more complex scenarios including non-linear trajectories and further physical parameters of the road users.

Goals

• This challenge aims to find and define new approaches for reducing the parameter search space such that the sampling time for the actual test case generation is substantially reduced. Especially for more complex scenarios, currently applied methods (based on mathematical equations) are reaching their limits. While ML-based approaches are not a must, they are also not excluded if a partner can provide corresponding expertise.
  

Team: AVL + TUG

Challenge: Learning-based fuzzing of AGL

Context

• Automotive Grade Linux (AGL) is an open-source operating system for automotive applications. The AGL project is trying to create a standard for in-vehicle software solutions by bringing together car manufacturers, suppliers, and software companies. Despite the fact that AGL is still very much in development, the first distributions are already available. To be part of this standardisation process, it is critical to ensure the reliability and security of such systems from the very beginning.

Goals

• The goal of this challenge is to test the different communication interfaces of an AGL demonstrator. Assuming a real scenario, we consider the AGL demonstrator as a black box where we can only execute inputs and observe the corresponding outputs. To address the challenge of an unknown state space, we aim to automatically build a behavioural model of the communication interface using model learning. This learned model is then the basis for creating a stateful black-box fuzzer.

Team: Westermo + ÅBO

Challenge: Continued test results data exploration

Context

• Automotive Grade Linux (AGL) is an open-source operating system for automotive applications. The AGL project is trying to create a standard for in-vehicle software solutions by bringing together car manufacturers, suppliers, and software companies. Despite the fact that AGL is still very much in development, the first distributions are already available. To be part of this standardisation process, it is critical to ensure the reliability and security of such systems from the very beginning.
  

Goals

• The idea is to schedule tests using both features of previous executions of the tests suite together with the results of the execution of the current test suite. One possible approach is to compute probability of failure for each test based on the history of previous executions and to explore binary correlations between tests, in other words, tests that failed together. This knowledge can be applied to adjust the schedule during the execution: if any test fails during the test session, the probability of failure of the correlated tests is increased and the schedule of tests waiting for execution is adjusted to these changes.