Networked standards for networked systems and processes

Smart, connected products for Industry 4.0 and the Internet of Things (IoT) are now being developed and produced in agile competence networks involving a multitude of new players. It is not necessarily essential to introduce new standards in order to ensure the exchange of information between the partners. Indeed, it might well be of greater use if we could intelligently combine the many standards that already exist and apply these more consistently.

Openness and standards are the prerequisites for smooth, trouble-free communication. Consequently, Industry 4.0 and IoT pose a major challenge when it comes to standardization because it has suddenly become necessary for very different elements to communicate with one another: The car must communicate with its environment, for example other vehicles or the car park; the systems installed in the vehicle must communicate between themselves, and their individual components may even have to communicate with the production and assembly equipment. It is therefore necessary to use IT to connect the products, processes and resources – an approach that departs from previous standardization practice. In the past, the standards describing products, processes and resources were all clearly delineated and separate from one another. That is why there is occasionally a call for one overarching standard which, if possible, should embrace all these requirements.

Understandable though this call is, it is also dangerous. The many decades of experience gathered in the field of standardization teach us that we do not have the time, money or, ultimately, the patience needed to develop this type of super-standard. And even if we did possess an abundance of all three ingredients, the effort to achieve standardization would probably be doomed to failure because the IoT is developing far too dynamically. In addition, a standard with the self-proclaimed goal of being able to describe everything would scarcely be compatible with an age in which everyone is singing the praises of federated IT systems and intelligently linked information. If products and systems are being, why not standards?

The trend is toward linking information rather than exchanging it, which is why OSLC is being lauded as the standard of the future, even though the idea of linking information via tags and anchors is almost as old as the Internet itself. However well these links may work within an enterprise by giving users system-independent access to information or linking together all the parties affected by a change, they cannot be used across company boundaries and firewalls. For this, we need good old-fashioned data exchange, which cannot work without standards. Indeed, standards are growing in importance as the need for collaboration increases.

Linking multiple standards

But what standards do we need? Starting with the assumption that the majority of communication requirements can be covered using existing standards, the ProSTEP iViP Association has taken a close look at the current environment. It found that for product descriptions alone, there is a vast set of national and international standards, which sometimes overlap at the functional level and whose advocates vie with one another. It is therefore time to do away with these outmoded attitudes.  

This not only means bidding farewell to older standards such as IGES and VDA-FS, whose maintenance is a drain on resources that might be better devoted to the implementation of new standards. It also means adopting a new way of thinking: Instead of vying with one another, we should agree about what the strengths of the individual standards are and then combine them. One good example of this pragmatic approach is the combination of STEP AP 242 XML and JT.

And the ProSTEP iViP Association is adopting a similarly pragmatic approach in the "Synced Factory Twin" project. The aim here is to close the information loop between development, production planning and production so that information can flow in both directions. However, this will not be achieved in the form of some all-embracing, definitive data model but by asking what information is really needed at what point in the process. And this information will then be made available by Development, via Production Planning, to the machine and returned from it by means of standards such as STEP AP 242 XML, AutomationML and OPC UA. It is possible that this combination will not cover every conceivable use case. However, with it, it is possible to cover 80 percent of cases at 20 percent of the effort.

Investing time in standardizations that will not be used is simply a complete waste of money. As early as 2012, the ProSTEP iViP and VDA Standardization Strategy Board chose the combination of STEP AP 242 XML and JT as the binding set of standards for geometry descriptions in the automotive industry. Despite formal commitments, this combination is still not being consistently applied throughout the industry. However, without it, cooperations such as that undertaken by Renault, Nissan and Daimler would be difficult to implement at the product data level. The three partners have proved that linked standards work.

Standards must prove themselves in practice

Of course, in the case of cybertronic products, information very different from geometry data has a role to play. This is due to the large number of electronic components and the software they involve and it is correct that no standards yet exist for the transfer of some of this information. However, it is already possible to exchange requirements via the ReqIF standard rather than in a document-based form, and behavioral models can be transferred to suppliers as functional modeling units (FMUs) via FMI interfaces, for example in order to simulate their interaction with other FMUs. The objection that the know-how contained in the FMUs is not fully protected is not an argument against using the standard. The basic mechanisms can perfectly well be used with trusted partners in order to gain some advance experience while simultaneously further developing the IP protection and security mechanisms.

Standards must prove themselves in practice. In Germany, we have a tendency to want to be 150% certain of everything and sometimes spend an eternity on our test activities. Things are very different at the Industrial Internet Consortium (IIC) in the USA, which develops and implements pragmatically standardized solutions for specific use cases in order to gather experience, which is then incorporated in the further development of the standards. We could do with a bit more of this pragmatism in Germany in order to benefit from the standards that we have been so instrumental in shaping. To standardize oneself is always better than to let oneself be standardized by others.