Composing Systemic Aspects into Component-Oriented DOC Middleware

The advent and maturation of component-based middleware frameworks have sim-plified the development of large-scale distributed applications by separating system devel-opment and configuration concerns into different aspects that can be specified and com-posed at various stages of the application development lifecycle. Conventional component middleware technologies, such as J2EE [73] and .NET [34], were designed to meet the quality of service (QoS) requirements of enterprise applications, which focus largely on scalability and reliability. Therefore, conventional component middleware specifications and implementations are not well suited for distributed real-time and embedded (DRE) ap-plications with more stringent QoS requirements, such as low latency/jitter, timeliness, and online fault recovery. In the DRE system development community, a new generation of enhanced commercial off-the-shelf (COTS) middleware, such as Real-time CORBA 1.0 (RT-CORBA)[39], is increasingly gaining acceptance as (1) the cost and time required to develop and verify DRE applications precludes developers from implementing complex DRE applications from scratch and (2) implementations of standard COTS middleware specifications mature and encompass key QoS properties needed by DRE systems. However, although COTS middleware standardizes mechanisms to configure and control underlying OS support for an application’s QoS requirements, it does not yet provide sufficient abstractions to separate QoS policy configurations such as real-time performance requirements, from application functionality. Developers are therefore forced to configure QoS policies in an ad hoc way, and the code to configure these policies is often scattered throughout and tangled with other parts of a DRE system. As a result, it is hard for developers to configure, validate, modify, and evolve complex DRE systems consistently. It is therefore necessary to create a new generation of QoS-enabled component middleware that provides more comprehensive support for addressing QoS-related concerns modularly, so that they can be introduced and configured as separate systemic aspects. By analyzing and identifying the limitations of applying conventional middleware technologies for DRE applications, this dissertation presents a new design and its associated techniques for enhancing conventional component-oriented middleware to provide programmability of DRE relevant real-time QoS concerns. This design is realized in an implementation of the standard CORBA Component Model (CCM) [38], called the Component-Integrated ACE ORB (CIAO). This dissertation also presents both architectural analysis and empirical results that demonstrate the effectiveness of this approach. This dissertation provides three contributions to the state of the art in composing systemic behaviors into component middleware frameworks. First, it illustrates how component middleware can simplify development and evolution of DRE applications while ensuring stringent QoS requirements by composing systemic QoS aspects. Second, it contributes to the design and implementation of QoS-enabled CCM by analyzing and documenting how systemic behaviors can be composed into component middleware. Finally, it presents empirical and analytical results to demonstrate the effectiveness and the advantage of composing systemic behaviors in component middleware. The work in this dissertation has a broader impact beyond the CCM in which it was developed, as it can be applied to other component-base middleware technologies which wish to support DRE applications

Second (Final) Report on EPOS-ICS Architecture

This deliverable describes the ICS-C final architecture. Based on user satisfaction with the architectural design and simple prototype of EPOS-PP (Preparatory Phase) the initial architecture was defined. During the period M1-M18 of EPOS-IP (Implementation Phase) the architecture was refined based on interactions with the TCS and presented at EPOS project meetings. During the period M19-M36 progressive iterative prototypes driven by evolving user requirements and aspirations have been developed allowing the architecture to be specified in much more detail and the components refined and implemented. For some components (ICS-D, CES) implementation is continuing because this requires especially close working with the TCS. Detailed work has been undertaken validating the ICS-C against the evolving and increasingly ambitious user requirements and – in particular – collecting the metadata describing the assets in the TCS to populate the catalog. The architecture has been designed using the latest advances in metadata (for the catalog) and architectural approach (microservices). A consistent spiral, agile systems development method has been used. As part of this work the teams of WP6 and WP7 of EPOS – each spread across several organisations – have been integrated into a functioning unit with appropriate skills and abilities for the tasks. There has been some delay in recruitment to provide the human resources required but this has been overcome and the work is on schedule

Robotics Software Engineering: A Perspective from the Service Robotics Domain

Robots that support humans by performing useful tasks (a.k.a., service robots) are booming worldwide. In contrast to industrial robots, the development of service robots comes with severe software engineering challenges, since they require high levels of robustness and autonomy to operate in highly heterogeneous environments. As a domain with critical safety implications, service robotics faces a need for sound software development practices. In this paper, we present the first large-scale empirical study to assess the state of the art and practice of robotics software engineering. We conducted 18 semi-structured interviews with industrial practitioners working in 15 companies from 9 different countries and a survey with 156 respondents (from 26 countries) from the robotics domain. Our results provide a comprehensive picture of (i) the practices applied by robotics industrial and academic practitioners, including processes, paradigms, languages, tools, frameworks, and reuse practices, (ii) the distinguishing characteristics of robotics software engineering, and (iii) recurrent challenges usually faced, together with adopted solutions. The paper concludes by discussing observations, derived hypotheses, and proposed actions for researchers and practitioners.Comment: 11 pages + 1 page for references, 3 figures, 3 tables, in proceedings of ESEC/FSE 202

Call to action for global access to and harmonization of quality information of individual earth science datasets

Knowledge about the quality of data and metadata is important to support informed decisions on the (re)use of individual datasets and is an essential part of the ecosystem that supports open science. Quality assessments reflect the reliability and usability of data. They need to be consistently curated, fully traceable, and adequately documented, as these are crucial for sound decision- and policy-making efforts that rely on data. Quality assessments also need to be consistently represented and readily integrated across systems and tools to allow for improved sharing of information on quality at the dataset level for individual quality attribute or dimension. Although the need for assessing the quality of data and associated information is well recognized, methodologies for an evaluation framework and presentation of resultant quality information to end users may not have been comprehensively addressed within and across disciplines. Global interdisciplinary domain experts have come together to systematically explore needs, challenges and impacts of consistently curating and representing quality information through the entire lifecycle of a dataset. This paper describes the findings of that effort, argues the importance of sharing dataset quality information, calls for community action to develop practical guidelines, and outlines community recommendations for developing such guidelines. Practical guidelines will allow for global access to and harmonization of quality information at the level of individual Earth science datasets, which in turn will support open science

PRODUCT LINE ARCHITECTURE FOR HADRONTHERAPY CONTROL SYSTEM: APPLICATIONS DEVELOPMENT AND CERTIFICATION

Hadrontherapy is the treatment of cancer with charged ion beams. As the charged ion beams used in hadrontherapy are required to be accelerated to very large energies, the particle accelerators used in this treatment are complex and composed of several sub-systems. As a result, control systems are employed for the supervision and control of these accelerators. Currently, The Italian National Hadrontherapy Facility (CNAO) has the objective of modernizing one of the software environments of its control system. Such a project would allow for the integration of new types of devices into the control system, such as mobile devices, as well as introducing newer technologies into the environment. In order to achieve this, this work began with the requirement analysis and definition of a product line architecture for applications of the upgraded control system environment. The product line architecture focuses on reliability, maintainability, and ease of compliance with medical software certification directives. This was followed by the design and development of several software services aimed at allowing the communication of the environments applications and other components of the control system, such as remote file access, relational data access, and OPC-UA. In addition, several libraries and tools have been developed to support the development of future control system applications, following the defined product line architecture. Lastly, a pilot application was created using the tools developed during this work, as well as the preliminary results of a cross-environment integration project. The approach followed in this work is later evaluated by comparing the developed tools to their legacy counterparts, as well as estimating the impact of future applications following the defined product line architecture.Hadrontherapy is the treatment of cancer with charged ion beams. As the charged ion beams used in hadrontherapy are required to be accelerated to very large energies, the particle accelerators used in this treatment are complex and composed of several sub-systems. As a result, control systems are employed for the supervision and control of these accelerators. Currently, The Italian National Hadrontherapy Facility (CNAO) has the objective of modernizing one of the software environments of its control system. Such a project would allow for the integration of new types of devices into the control system, such as mobile devices, as well as introducing newer technologies into the environment. In order to achieve this, this work began with the requirement analysis and definition of a product line architecture for applications of the upgraded control system environment. The product line architecture focuses on reliability, maintainability, and ease of compliance with medical software certification directives. This was followed by the design and development of several software services aimed at allowing the communication of the environments applications and other components of the control system, such as remote file access, relational data access, and OPC-UA. In addition, several libraries and tools have been developed to support the development of future control system applications, following the defined product line architecture. Lastly, a pilot application was created using the tools developed during this work, as well as the preliminary results of a cross-environment integration project. The approach followed in this work is later evaluated by comparing the developed tools to their legacy counterparts, as well as estimating the impact of future applications following the defined product line architecture

The Pipeline for the Continuous Development of Artificial Intelligence Models -- Current State of Research and Practice

Companies struggle to continuously develop and deploy AI models to complex production systems due to AI characteristics while assuring quality. To ease the development process, continuous pipelines for AI have become an active research area where consolidated and in-depth analysis regarding the terminology, triggers, tasks, and challenges is required. This paper includes a Multivocal Literature Review where we consolidated 151 relevant formal and informal sources. In addition, nine-semi structured interviews with participants from academia and industry verified and extended the obtained information. Based on these sources, this paper provides and compares terminologies for DevOps and CI/CD for AI, MLOps, (end-to-end) lifecycle management, and CD4ML. Furthermore, the paper provides an aggregated list of potential triggers for reiterating the pipeline, such as alert systems or schedules. In addition, this work uses a taxonomy creation strategy to present a consolidated pipeline comprising tasks regarding the continuous development of AI. This pipeline consists of four stages: Data Handling, Model Learning, Software Development and System Operations. Moreover, we map challenges regarding pipeline implementation, adaption, and usage for the continuous development of AI to these four stages.Comment: accepted in the Journal Systems and Softwar