Within the Smart Grid scope, the generic Smart Grid Architecture Model SGAM acts as a reference designation system for systems and component allocation in order to describe Smart Grid (technical) use cases as well as business cases for requirements engineering purposes. It has been successfully applied in the scope of the EU M/490 mandate to CEN, CENELEC and ETSI as well as to various EU Framework Program 7 projects with regards to Smart Grid legacy system renovation, first adaptations of the model in other domains like maritimae and Industry 4.0 and scopes have been tried out, see [UE15]. In this contribution, we elaborateon this model and outline its core aspects from the modeling point of view as well as implications for the model-driven engineering process in the Industrie 4.0 domain as the RAMI 4.0 approach.
The SGAM and its methodology was originally intended to (re-)present the design and technologies of Smart Grid use cases from both an architectural and technology-neutral manner [CEN12]. In addition, the three-dimensional view provides for a separation of various viewpoints in systems development. The SGAM had to be constructed for practical purposes. In the utility domain, vendors had a monopoly in terms of selling monolithic systems to their customers which were used to pay high prices due to their assured revenue in terms of corporate profits. With the "Energiewende", new operations paradigm led to a lot of new interfaces to distributed systems, sensors, DER generation and more operational data being gathered due to operational optimization needs. The Smart Grid topic emerged. The utilities were not ready for the new IT paradigm and technologies needed. Little knowledge about conceptual modelling, enterprise architecture management, systems engineering and service-oriented architectures was present in their IT-department since the usually relied on integrators, OEMs and vendors for turn-key solutions. Custom interfaces based on new user requirements for new business processes became somewhat of a problem. No domain specific UML tools existed, PowerPoint and Visio were the choice for modelling IT and landscapes and no emphasis was on a standardized semantic and syntax. So introducing modelling for Smart Grids relies on learning all domain specific requirements, proprietary tooling and processes for the Computer Science savvy integrator. The focus had to be on a method which hid its theoretical foundation (e.g. the ISO / IEC 42010 meta-modelling for architectures standard), made the aspect of organisational scope, IT-Level and value creation chain comprehensible to the stakeholder at the utility. In general, the way from a simple use case template with an iterative (and maybe agile) process to code generation taking into account the limited modelling background of the stakeholders and their domain requirements into account was needed.
The SGAM consists of five consistent and canonical used layers representing use cases, information models, communication protocols and components. Each layer covers a so called Smart Grid plane, which is spanned by domains (the value creation chain). The intention of the reference designation model is to allow the presentation of the current state of implementations in the electrical power grid, but additionally to present the evolution to future Smart Grid scenarios by supporting the principles of extensibility, scalability, upgradability in its core. The domains modelled in the SGAM take into account mainly the energy conversion chain and include: generation (both conventional and renewable bulk generation capacities), transmission (infrastructure and organization for the transport of electricity across long distances), distribution (infrastructure and organization for the distribution of electricity to the customers both industry and private households), DER (distributed energy resources connected to the distribution grid, directly to the grid) and customer premises (both end users and producers of electricity; including industrial, commercial, and home facilities as well as generation in form of, e.g., photovoltaics conversion, electric vehicles storage, batteries, as well as micro turbines) [EU12]. The hierarchy of power system management and operations from the automation perspective as well as utility organizational level perspective is reflected within the SGAM by the very definition of the following zones in scope: process (physical, chemical or spatial transformations of energy and the physical equipment directly involved), field (equipment to protect, control and monitor the process of the power system), station (areal aggregation level for field level), operation (power system control operation in the respective domain), enterprise (commercial and organizational processes, services and infrastructures for enterprises), and market (market operations possible along the energy conversion chain). Finally, as it constitutes a major requirement towards distributed systems, the SGAM defines so called Interoperability Layers based on the GWAC (GridWise Architecture Council) IOP stack [EU12]. One important aspect to take into account when transferring the modelling approach from the SGAM to new domains is the original scope of the SGAM model. Based on the work from the EU M/490 mandate, the original purpose was modelling the landscape of existing CEN, CENELEC and ETSI standards in order to find gaps for needed future Smart Grids standards and show relations between existing work items and working groups. Previous work like the conceptual Smart Grid model from NIST (National Institute of Standards and Technology) had shown that, in order to distinguish between various aspects of Smart Grid solutions, more than one viewpoint from the stakeholders has to be covered. Based on the original scope, the SGAM can be considered only a reference designation system rather than a reference architecture model [UE15].
Very little rules for filling out SGAM model cubes actually exist in the community, certain shapes are not defined by some kind of (visual/ graphical) standard, the focus is on the reference designation system. Filling out an SGAM model can be considered as some kind of "visual key-wording" for the use case stakeholder, providing a way to put each part embodied in a Smart Grid solution in context of the value chain, interoperability dimension and internal utility organization [NUE+16]. The aspect of "reference" is defined by the content modelled in this reference designation system and its visualisation, the requirements and functions for a solution can act as a blue-print for own developments based on the documented existing best practice.
Within various projects, SGAM has proven to be a very useful tool for knowledge sharing about (technical) Smart Grid solutions [NUE+16, NEU16, NEE+15, UG15 and GU15] and focus on analysing the systems with various viewpoints like organisational scope, security, technical portfolio or process dimension. Using a structured way to elicit requirements with a template, it can be assured that enough information is elicited in order to create a RAMI 4.0 architecture model of a technical Industrie 4.0 use case. Both tools share the same ISO/IEC 42010 meta-model and are aligned. With the assured data quality, the technical solutions and its inherent architecture can be visualized for either stakeholder discussions or visual analytics. Interfaces, data exchanged as well as Application Programming Interfaces (API) are documented and become subject to discussion. As this step takes place in an early stage of a project, harmonizing and aligning requirements for both functional aspects as well as non-functional aspects lowers integration and development costs. Important information on interfaces and data exchanges like technical standards, payloads, Qualityof-Service, Uptime etc. can be discussed and assessed [UM15]. The RAMI 4.0 covers different dimensions than the SGAM but the original method and toolchain can be adopted to those changes. The RAMI 4.0 derivate of the original SGAM domain approach typically follows the interoperability stack rules for the technical solutions as defined by SGAM because those viewpoints to be taken from the stakeholder perspective are usually a natural fit for (technical) development projects in the context of automated systems-of-systems (See figure 3). Some basic design rules for modelling the envisioned technical use cases in the three dimensions have to be followed in order to make various metrics, style guides and tooling work with the new model [UE15]. The approach presented in this contribution takes advantage of the fact that the RAMI shares a lot /most of basic design principles with the SGAM, thus, making a transfer of the SGAM visualization to the scope of Industry 4.0 possible. This section provides a very brief introduction to the RAMI model, focusing on the most important changes from the modelling paradigm point of view in requirements engineering and domain engineering perspective.
The Reference Architecture Model for Industry 4.0 (RAMI 4.0) [DIN16] is the most sophisticated derivative of the SGAM as of today, developed by ZVEI in Germany.
Based on the discussed German Industry 4.0 concept, the main aspect is the re-use of the GWAC interoperability stack being the automation pyramid. In addition to business, function, information, communication and asset representing component, a new layer called integration (for the Industry 4.0 component meta-information) is introduced. The model shall harmonize different user perspectives on the emerging topic of Industry 4.0 on the overall level and provide a common understanding for the stakeholders on the relations between individual components for Industry 4.0 solutions from different vendors. Different industrial sub-sectors like automation, engineering and process engineering all have to agree on a common view on the overall systems landscape. The SGAM principles for the scope of locating standards is re-used in the RAMI paradigms, also using the RAMI 4.0 it as a reference designation system. One of the next steps for creating the modelling paradigm for RAMI 4.0 is to come up with so called "101 examples" for Industry 4.0 solutions in the RAMI (see figure 4 and 5), provide proper means for the devices to be identified and provide discovery service modelling for those devices, harmonize both syntax and semantics and focus on the main aspect of the integration layer which was introduced in order to properly model the communication requirements in factory automation. This will lead to both a higher adoption based on the initial ramp up of knowledge to be gathered in addition to the benefits which become more obvious once the model in used by a broader audience.
Within this contribution on modelling for Industry 4.0, we are going to visualize an example from the factory automation domain, a model of a yoghurt filling plant provided by the Pepperl+Fuchs Group for ZVEI and modelled by OFFIS.
One issue of a reference designation model is finding good examples for the users to give them a hint how to use the three-dimensional model in a meaningful way. The aspect of use case management has been addressed form the domain perspective already at various levels, e.g. in the Smart Grid by using a standardized IEC 62559-2 template for use case management [UM15].
The RAMI 4.0 has taken over a similar tooling approach to the SGAM, focusing on providing meaningful PowerPoint based two-dimensional, narrative first examples. This proves for a quick win solution by graphically addressing architectural relations between systems and their data exchanges. One drawback when applying the method chain from the Smart Grid to the Industry 4.0 scope is that there is no harmonized, common metamodel template for use case management and elicitation like the IEC 62559-2 for Smart Grids [UG15b]. For the overall scope of domain specific modelling, this is not much of a problem since the RAMI will cover a systems engineering approach where standardized tools and languages for requirements engineering like SysML (Systems Modelling Language), ReqIF (Requirements Interchange Format) and tools like Rational DOORS or Sparx Enterprise Architect (EA) exist. However, a common meta-model of a requirements elicitation template and the architecture model (based on ISO 42010 as well as the content of the layers) would make for an easier transformation and creation of test models from use cases. The original tool for the Smart Grid domain was developed with the useful paradigm of excluding hardcoded domains, zones and layers and could be easily adopted for the new domains, thus, providing a meaningful requirements engineering process for systems engineering as well as tooling.. The overall solution is a browser-based, hosted service for rendering the architecture models with an import interface for Spreadsheet based node-edge based models (Simple Excel spreadsheets). Within figure 5, the spreadsheet created from the yoghurt filling machine example is depicted.
In order to properly communicate about the models, a fully navigable 3D-model has been developed which is depicted in figure 4 of this paper. The tool can import models, and in addition to graphics, show metadata on the objects visualized in the RAMI 4.0 stack. In addition to the graphical aspect of the model, various manipulations like omitting individual layers, rotation, slicing and exporting graphics to lossless PNG and JPEG can be performed. Therefore, the tool can also act as a modelling tool to visualize generic RAMI node-edge based graphs that can be easily converted from semi-formal CSV files to generated graphics for presentation for PowerPoint in meetings or needed documentation for the architect of a use case.
Model-driven Requirements Engineering Using RAMI 4.0 Based Visualizations 27 The rendered entities can have various shapes as well as textures which can be fully configured in the client (i.e. the browser) used. The solution is browser-based, supports most current browsers and needs no installation of plug-ins or runtime environments. In the future, a model repository as well as a so called RAMI 4.0 toolbox in Sparx Enterprise architect will be developed, providing the same functionality for the development process as the SGAM toolbox for the Smart Grid and making export to the rendering format possible. In addition, new models in the context of Industry 4.0 will be modelled, e.g. the ju-RAMI with links to the corresponding laws at http://www.gesetzeim-internet.de, providing a visual navigation tool for the contents of the ju-RAMI. In addition, work on modelling the Industrial Internet Reference Architecture (IIRA) from the Industrial Internet Consortium (IIC) will provide the possibility to render and load both IIC as well as RAMI 4.0 models in one tool and find, e.g., semantically equivalent services [Kl+16].
Based on the work in Smart Grids, the applicability of the approach as well as the adequacy can be validated. Stakeholders provide requirements using a standardized IEC 62559 use case template which covers the relevant aspects for elicitation of the domain IT experts. Based on this information and the common meta-model, a preliminary architecture can be generated, showing very important viewpoints as aspects for additional discussion. This is usually a huge benefit as it shortens the time for discussing the architectural implications with the stakeholders. In addition, the very model can be imported into UML (Unified Modelling Language) tools for domain-driven engineering approaches. The concept has shown to be applicable to systems engineering in general.
The approach has been taken up by the IEC SRG. The Systems Resource Group (SRG) is a group of Systems Methodology experts whose purpose is to guide the development and use of specialized tools and software applications for Systems, and encourage the use of these tools and sharing of best practices within the Systems Committees. The Systems Resource Group serves as a support and consulting resource to Systems Expert Group (SEGs) and SyCs (Systems Committees). It also specifies tools and provide guidance for Systems Approach Methodology such as architecture models, road maps and use cases. IT focuses on the science of system standardization, but does not engage in technical standards work. In addition, first transfer has been done, e.g. in the context of Industry 4.0. Within this contribution we have shown basics of the approach and its theoretical foundation for visualizing Industry 4.0 models with very little effort and strong re-use.