Cyber-Physical Systems are designed and developed using multi-disciplinary teams.Handovers from one discipline to another often occur using text documents written in natural language, which can be imprecise, ambiguous, and lead to errors.To improve this situation, we created a textual Domain Specific Language with live graphical feedback to enhance the handover between mechanical and mechatronic engineers working on medical robots at Philips IGT.The Domain Specific Language formalizes the system description and provides immediate live graphical feedback to prevent mistakes from being made, such as editing the wrong physical parts and by visualizing the differences of two versions of a system.In addition, our approach leverages multiple industry standards and it enables bi-directional navigation between languages.

The lack of explicit and precise specifications of software interfaces between components often leads to integration issues during development and maintenance. To address this, we have developed a framework named ComMA (Component Modeling and Analysis) that supports model-based engineering of high-tech systems by precisely defining components and their interfaces. The framework is a family of Domain Specific Languages (DSLs) for modeling component interfaces, protocol state machines, time and data constraints, and constraints on relations between events of multiple interfaces. From these models a number of artifacts can be generated automatically to support analysis and various engineering tasks. ComMA has been developed in close collaboration with the Philips IGT business unit that develops minimally-invasive X-ray systems. This paper presents the experience we gained in creating the ComMA framework and its application in industrial practice. We describe and reflect on the technical, organizational and process-related aspects of deploying a non-trivial MDE solution in an industrial setting.

We present our vision for creating an industrial legacy software rejuvenation toolchain. The goal is to semi automatically remove code smells from stateful software used in Cyber Physical Systems (CPS). Compared to existing tools that remove code smells, our toolchain can remove more than one type of code smell. Additionally, our approach supports multiple programming languages because we use abstract models obtained by means of model learning. Supporting more than one programming language is often lacking in state of art refactoring tools.

Abstract This is an industrial experience report on a large semi‐automated migration of legacy test code in C and C++. The particular migration was enabled by automating most of the maintenance steps. Without automation this particular large‐scale migration would not have been conducted, due to the risks involved in manual maintenance (risk of introducing errors, risk of unexpected rework, and loss of productivity). We describe and evaluate the method of automation we used on this real‐world case. The benefits were that by automating analysis, we could make sure that we understand all the relevant details for the envisioned maintenance, without having to manually read and check our theories. Furthermore, by automating transformations we could reiterate and improve over complex and large scale source code updates, until they were “just right.” The drawbacks were that, first, we have had to learn new metaprogramming skills. Second, our automation scripts are not readily reusable for other contexts; they were necessarily developed for this ad‐hoc maintenance task. Our analysis shows that automated software maintenance as compared to the (hypothetical) manual alternative method seems to be better both in terms of avoiding mistakes and avoiding rework because of such mistakes. It seems that necessary and beneficial source code maintenance need not to be avoided, if software engineers are enabled to create bespoke (and ad‐hoc) analysis and transformation tools to support it.

At Philips IGT, we develop and produce interventional X-ray systems. For a controller in these systems, we have an approximately five years old domain specific language. Like general programming languages, domains specific languages also evolve. These languages co-evolve together with their domain. The language used at IGT was initially created for one system instance. Because of our positive experiences with the language, we want to evolve the language to support a family of systems. In this paper, we report on our experiences with the modifications we made to the original language. We made these changes preserving the behavior of the existing system instance. To prevent confidentiality issues, we use a Lego robot in our examples.

Over time, software tends to grow more complex, hampering understandability and further development. To reduce accidental complexity, model-based rejuvenation techniques have been proposed. These techniques combine reverse engineering (extracting models) with forward engineering (generating code). Unfortunately, model extraction can be error-prone, and validation can often only be performed at a late stage by testing the generated code. We intend to mitigate the aforementioned challenges, making model-based rejuvenation more controlled. We describe an exploratory case study that aims to rejuvenate an industrial embedded software component implementing a nested state machine. We combine two techniques. First, we develop and apply a series of small, automated, case-specific code refactorings that ensure the code (a) uses well-known programming idioms, and (b) easily maps onto the type of model we intend to extract. Second, we perform model-based rejuvenation focusing on the high-level structure of the code. The above combination of techniques gives ample opportunity for early validation, in the form of code reviews and testing, as each refactoring is performed directly on the existing code. Moreover, aligning the code with the type of model we intend to extract significantly simplifies the extraction, making the process less error-prone. Hence, we consider code refactoring to be a useful stepping stone towards model-based rejuvenation.

Cyber-physical systems consist of many hardware and software components.Over the life-cycle of these systems, components are replaced or updated.To avoid integration problems, good interface descriptions are crucial for component-based development of these systems.For new components, a Domain Specific Language (DSL) called Component Modeling & Analysis (ComMA) can be used to formally define the interface of such a component in terms of its signature, state and timing behavior.Having interfaces described in a model-based approach enables the generation of artifacts, for instance, to generate a monitor that can check interface conformance of components based on a trace of observed interface interactions during execution.The benefit of having formal interface descriptions also holds for legacy system components.Interfaces of legacy components can be reverse engineered manually.In order to reduce the manual effort, we present an automated learner.The learner can reverse engineer state and timing behavior of a legacy interface by examining event traces of the component in operation.The learner will then generate a ComMA model.

Contains fulltext : 173201.pdf (Publisher’s version ) (Open Access)

The high-tech industry produces complex devices in which software plays an important role. Since these devices have been developed for many decades, an increasing part of the software can be classified as legacy which is difficult to maintain and to extend. To improve the maintainability of legacy components, domain specific languages (DSLs) provide promising perspectives. We present a DSL for creating configuration files that describe the topology of a fieldbus. This DSL improves the maintainability and extensibility of a legacy component. Compared to the current way-of-working, the configuration files generated by the DSL are of higher quality due to the concise representation of DSL instances and additional validation checks. To raise the level of abstraction even more, we have created a second DSL which allows a concise description of system configurations and the generation of topologies.

We evaluate the effect of applying the commercial formal technique Analytical Software Design (ASD) to an industrial project. In ASD, interfaces and software designs are modelled using a formal tabular notation. The ASD tool set supports formal checks of these models, such as deadlock freedom and interface compliance. In addition, full code can be generated from design models. ASD has been applied at Philips Healthcare to develop parts of the software of interventional X-ray systems. We report about the experiences with the embedding of ASD into the development processes. The quality of the resulting code and the productivity has been analysed and compared to code developed with other techniques. We observe that the use of ASD leads to a strong reduction of the number of defects and an increase in productivity. The results are also compared to the literature about standards and related projects at other companies.

To improve the design of a power control unit at Philips, two Domain Specific Languages (DSLs) have been used.The first DSL provides a concise and readable notation for the essential state transitions.It is used to generate both configuration files and analysis models.In addition, we also generate instances of a second DSL which represents test traces.This second DSL is used to generate test cases for the power control unit.The use of DSLs not only improved productivity, but also the quality of the configuration files and the test set.• How much time is needed to learn the tools and techniques?• How much effort is needed to migrate the current legacy component to a component which is defined by a highlevel human-usable DSL?• Does the DSL approach support the combination with analysis techniques such as simulation tools and formal