The December newsletter for the Adeptness project is available for download. Click on the button to donwload it.
The main purpose of this deliverable is to develop and maintain an exploitation plan containing a credible path to deliver innovations to the market. The plan will be proportional to the scale of the project and contains measures to be implemented both during and after the project.
The purpose of this deliverable is to present the dissemination plan of the ADEPTNESS project over the project’s duration.
This deliverable is a guideline that will specify project items to be communicated, target audience, timing and means of communication (e.g., newsletter, public event) for each communication item specified.
This document shows the approach followed to define the microservices APIs and architecture for the Adeptness project. The document starts with an introduction to microservices architectures and their applicability in Adeptness, following with the definition of the common interface that has been designed for all the Adeptness microservices. In the next section, the definition of the APIs, communications, and interactions for each of the subsystems and microservices that conform the Adeptness architecture takes place. Finally, guidelines for including microservices not included in the initial Adeptness architecture are provided.
This document describes the requirements of the different components of the ADEPTNESS workflow, the architecture of the design-operation continuum methods and the workflow to be developed in the project. It also contains the Ethics checking results.
Elevators are among the oldest and most widespread transportation systems, yet their complexity increases rapidly to satisfy customization demands and to meet quality of service requirements. Verification and validation tasks in this context are costly, since they rely on the manual intervention of domain experts at some points of the process. This is mainly due to the difficulty to assess whether the elevators behave as expected in the different test scenarios, the so-called test oracle problem. Metamorphic testing is a thriving testing technique that alleviates the oracle problem by reasoning on the relations among multiple executions of the system under test, the so-called metamorphic relations. In this practical experience paper, we report on the application of metamorphic testing to verify an industrial elevator dispatcher. Together with domain experts from the elevation sector, we defined multiple metamorphic relations that consider domain-specific quality of service measures. Evaluation results with seeded faults show that the approach is effective at detecting faults automatically.
Authors: Jon Ayerdi∗, Sergio Segura†, Aitor Arrieta∗, Goiuria Sagardui∗ and Maite Arratibel
Mondragon Unibertsitatea∗, Universidad de Sevilla †, Orona ‡
Invited talk 1: Automating the design-operation continuum of Cyber Physical Systems of Systems (Goiuria Sagardui, MGEP)
At the DepDevOps workshop on SafeComp 2020, the 39th International Conference on Computer Safety, Reliability and Security
Software systems that are embedded in autonomous Cyber-Physical Systems (CPSs) usually have a large life-cycle, both during its development and in maintenance. This software evolves during its life-cycle in order to incorporate new requirements, bug fixes, and to deal with hardware obsolescence. The current process for developing and maintaining this software is very fragmented, which makes developing new software versions and deploying them in the CPSs extremely expensive. In other domains, such as web engineering, the phases of development and operation are tightly connected, making it possible to easily perform software updates of the system, and to obtain operational data that can be analyzed by engineers at development time.
However, in spite of the rise of new communication technologies (e.g., 5G) providing an opportunity to acquire Design-Operation Continuum Engineering methods in the context of CPSs, there are still many complex issues that need to be addressed, such as the ones related with hardware-software co-design. Therefore, the process of Design-Operation Continuum Engineering for CPSs requires substantial changes with respect to the current fragmented software development process. In this paper, we build a taxonomy for Design-Operation Continuum Engineering of CPSs based on case studies from two different industrial domains involving CPSs (elevation and railway). This taxonomy is later used to elicit requirements from these two case studies in order to present a blueprint on adopting Design-Operation Continuum Engineering in any organization developing CPSs.
Authors: Jon Ayerdi∗ , Aitor Garciandia† , Aitor Arrieta∗ , Wasif Afzal‡ , Eduard Enoiu‡ , Aitor Agirre† , Goiuria Sagardui∗ , Maite Arratibel§ and Ola Sellin¶
University of Mondragon ∗, Ikerlan †, Malardalen University ‡, Orona §, Bombardier Transportation ¶,