Experts' opinion: How do partners in CRYSTAL evaluate the applicability of project results and what do they expect of the IOS

How do you see the development of the IOS over the last years?
Loiret: The IOS has been a hot topic within the ARTEMIS eco-system, pioneered in 2009 by the CESAR and iFEST projects with the idea to establish the cornerstone principles of a standardized and cross-domain integration approach for engineering tools and data. With such an ambitious goal in mind, it has been required to build up a common understanding of the end-users’ integration needs and to reach consensus across a wide range of stakeholders regarding technical issues and adoption of standards, the more so across project consortia (since MBAT, CRYSTAL, and more recently EMC2 are based on the underpinning concepts of the IOS). In this context, the development of the IOS has gone through an iterative and continuous process, leveraging on an increasing momentum brought by these European initiatives. Presently, the cornerstone principles of the IOS are widely accepted, constituting a cross-project baseline on which further project specific enhancements of the IOS are being developed.
Rotibi: In CRYSTAL, we are conducting a survey this summer to find out how all project partners see the interoperability strategy and how satisfied they are with the project so far. More over, we would like to find out how the working groups could further cooperate. Survey results are expected in September and the publication of the results will probably be in October 2014.

Mr Schwarz, Daimler has been coordinator of the project MBAT, in which the CESAR version of the IOS was further developed and used for applications. In which R&D areas does Daimler use the IOS results from MBAT and its follow up projects?
Schwarz: Indeed, the CESAR IOS has been extended by MBAT to also include V&V technologies and its data. During the runtime of MBAT the IOS has been used to support several use cases and the corresponding tool chains. In this respect, also the ENOVIA and JAZZ platforms provided by Dassault Systems and IBM have contributed important technical means to support the development of the MBAT IOS. The IOS results of MBAT are planned to be used in a pilot project starting in 2015 which involves all the relevant tool chains and IOS concepts that have been developed in Daimler use cases during the runtime of MBAT. IOS is also an important topic for future tool integration projects at Daimler.

Mr Bräuchle, what are the advantages of interoperable tool chains for PTC?
Bräuchle: Today’s challenges in safety-critical systems engineering cannot be addressed by just one single-vendor tool chain because of the multiple engineering disciplines that are involved in the development process of such complex systems. A truly interoperable tool chain addresses the specific needs in each engineering discipline through best-of-breed capabilities while ensuring seamless integration of the results. We see three key points in open, interoperable tool chains:
A complete interoperable systems engineering environment requires open interfaces to tools and repositories from other vendors, which excel in their specialties.
Many large engineering organizations pursue a multi-vendor strategy for their development environment to mitigate the risks that arise from depending on only one tool-vendor. Through open interfaces we can complete or replace pre-existing parts of the development tool chain.
Interoperability is imperative for our own systems engineering solutions as they integrate functionalities from different products.

The IOS fosters interoperable tool chains which suits the end user community especially. Does the IOS provide new business opportunities for the vendor community?
Loiret: Leveraging on standardized integration interfaces for implementing system engineering environments is a key point of the IOS. A wide adoption by engineering tool providers of standardized data across domains and engineering disciplines will expand the market to new opportunities, in particular in the area of lifecycle and added-value tools & services to be implemented on top of it. These new business opportunities will be harnessed by large integration solution providers regarding generic lifecycle services, but also by SMEs, which will tap into new niche markets with ready-to-integrate and bespoke added-value tools tailored to end-users’ specific needs and businesses.
Rotibi: Can you imagine what kind of tools would be possible if the IOS would be industry wide applied? The seamless integration of tool chains will be facilitated, new tools adopting the changed conditions will arise, and the complexity of the development process during the whole product life cycle will be effi­ciently manageable. With new types of application a new type of ecosystem could grow up on top of that.
Moreover, a favorable side effect will be a tighter collaboration of the vendor and end user community. There is a lot to be gained as business benefits for both, the vendor and the end user community.

What do you think about OSLC as basis for the IOS?
Ekkel: I think OSLC is really suitable. It exists for more than 5 years and has been proven in use in various tools. There are parts of the IOS already implemented in OSLC and it has huge addional potential. The strength of OSLC is especially in connecting, editing and displaying data.
Anyway, OSLC is not suitable for all kind of requirements so far, e.g. not for real time constraints. We are working on extensions of OSLC in that direction and hope to be successful in year 2 or 3 of the project.

"OSLC will be extended to further cover the IOS."

Schwarz: In MBAT we could collect some experiences with OSLC and we confirmed that this is a possible implementation for parts of the IOS. Although OSLC is already addressing major concepts of the IOS, the IOS involves many more technical and discipline specific issues that are not integrated yet, as Rob mentioned.
Bräuchle: We see OSLC as the best public available specification for interoperability in engineering tool chains and it has gained significant momentum in the industry over the past few years. Thanks to the efforts of the early contributors, it is based on modern web based technology and even comes with a fairly mature development kit.
However, there are downsides and limitations due to the nature of OSLC. It limits semantics and functionality down to a lowest common denominator, which means that some integration scenarios are either addressed outside the current specification or that the definitions are misapplied as kind of envelopes for application specific content and semantics. Finally the implementation of OSLC specifications can be quite challenging in desktop-based tools that solve very specific engineering tasks, but are not web-enabled or have no server components.
Loiret: From a technical standpoint, OSLC relies on seductive principles stemming from software engineering, and heavily reusing existing and already widely adopted standards from the Internet eco-system, and it is a brilliant idea to apply them in the context of systems engineering environments. Indeed, could one think about an IT infrastructure that has been more widely adopted than Internet for connecting data and people together? However, it is a requirement to extend the existing OSLC specifications for fulfilling specific systems engineering needs elicited by the end-users, an on-going effort being conducted in our projects.
Finally, Christoph touched on that topic, it is also worth mentioning that there is a growing momentum around the support of OSLC by tool providers and end-users beyond our IOS related European projects, a mandatory lever towards its wider adoption

What should be the next steps to establish the IOS?
Albers: As mentioned above, we need to extend the IOS and its implementation with OSLC and also with other standards.
I would like to give a concrete exam­ple of next steps for the IOS in the scope of requirements engineering. We use an engineering method for one step in the development process - in this case from the healthcare domain - and employ this method in use cases from all the CRYSTAL application domains. We use this to find missing  requirements for the IOS in each domain. After several engineering steps, we gain a complete outline of IOS requirements which we can implement in the tools.
Bräuchle: As Rob explained, the first part will be to identify and close gaps in the specifications, especially in OSLC where they are not yet sufficient to support relevant engineering methods, which describe the interactions between different tools from a use case perspective. In this context “closing gaps” might include not only the enhancement or augmentation of existing OSLC specifications, but also require new specifications to address e.g. issues around versioning and variability.
The second part requires the identification of areas where OSLC does not provide the path to success and more (domain-) specific interoperability specifications are appropriate. This includes purpose-made definitions and standards such as ReqIF (Requirements Interchange Format) or the FMI (Functional Mockup Interface). It will be an important and significant task to accurately place these already available standards in the greater IOS context by determining the boundaries, dependencies and lines of interaction.
Schwarz: Above technical issues, the commitment of European industrial key players in the domain of embedded systems development to an IOS is crucial. Thus we have to foster the commitment of a sufficient number of industrial partners supporting this IOS.
Loiret: To this point I can add, that since the IOS related activities have been so far spread over multiple initiatives, complementary to each others, it would be beneficial to put on place an open, cross-projects and lightweight structure establishing a sustainable roadmap for the IOS. Such a structure would provide support and guidelines to the projects in order to speed-up the IOS adoption process in future consortia; to streamline the elicitation of interoperability needs from the end-users; and to support cooperation of IOS pre-standardization activities. It becomes also urgent to establish concrete and more formal interactions with the standardization bodies to which the IOS would be anchored. Last but not least, such a lightweight structure would also provide support for enhancing and maintaining full-fledged IOS sustainable demonstrators. We are currently actively working on these issues.

"The IOS reduces effort."

What are your goals and hopes regarding the IOS?
Loiret: Nowadays, the rapid growth of software-intensive applications in our physical world and daily lives drastically increases the needs of engineering tools & data interoperability. In this context, I do believe that establishing a common and standardized baseline building on the IOS is the way to move forward. My goals are currently to contribute to reaching consensus among the IOS stakeholders and their respective interests, and to focus on sustainable demonstrators showing how the Systems Engineering community can benefits from IOS based solutions for streamlining their development processes.
Bräuchle: We hope not only for a wider adoption of publicly defined interoperability standards and specifications, but also for the correct usage of these - i.e. that the technical implementations also consider the intended use and the context of these specifications. The industrial use cases in the CRYSTAL project encourage this hope. Based on this we aim at a more standardized implementation of our own APIs, reducing the number of proprietary interfaces and integrations and therefore lowering maintenance cost.
Schwarz: The project activities will merge into one solution of concept and specification. The IOS reduces the effort to integrate tools into customer specific tool chains and enables new applications with improved usability to support our engineers on the job. There will be a wide range of IOS-supported tools. As an OEM we would like to see a benefit regarding an improved embedded systems development process in terms of quality and time supported by the IOS.
Ekkel: We hope that the big tool providers like IBM, PTC, Dassault Systems etc. adopt the IOS and implement it. There should be no more vendor lock-in so that we can choose the tools that fit best in a certain context. We wish the IOS to fly.
Albers: I agree with Rob, we hope that with the IOS it is possible to create more efficient R&D processes for our company and that we can handle even more complexity thanks to a better overview.
Rotibi: My personal goals are tied up with the CRYSTAL survey. Finally, I hope that there is a common agreement of extentions of the IOS and its implementation, especially of the strategy towards a practical solution.
Last but not least, I hope that in the future, we can bring projects like CRYSTAL from a European to a global level. That will be a big challenge but the benefits of world wide cooperation within development processes for embedded and cyber-physical systems will be huge.

Thank you very much for the interviews!