ChapterPDF Available

Certification as a Service

Authors:

Abstract and Figures

The development of industry 4.0 and smart energy IT-Components relies on highly standardized communication protocols to reach vendor-independent interoperability. In innovative and fast-changing environments, the support of standard protocols increases the time to market significantly. In the energy domain, the business models and the regulatory frameworks will be updated more often than the protocols. Thus agile development and supporting standardized protocols at the same time seems to be an issue. Here we will present a new proposal for standardization and certification processes as well as an architecture for a certification platform. Both will improve the support of agile development in the industry and energy domain.
Content may be subject to copyright.
Certification as a Service
Sebastian Copei1(B
), Manuel Wickert2,andAlbertZ¨undorf1
1Kassel University, Kassel, Germany
{sco,zuendorf}@uni-kassel.de
2Frauenhofer IEE, Kassel, Germany
manuel.wickert@iee.frauenhofer.de
Abstract. The development of industry 4.0 and smart energy IT-
Components relies on highly standardized communication protocols
to reach vendor-independent interoperability. In innovative and fast-
changing environments, the support of standard protocols increases the
time to market significantly. In the energy domain, the business models
and the regulatory frameworks will be updated more often than the pro-
tocols. Thus agile development and supporting standardized protocols at
the same time seems to be an issue. Here we will present a new proposal
for standardization and certification processes as well as an architecture
for a certification platform. Both will improve the support of agile devel-
opment in the industry and energy domain.
Keywords: Microservices ·Standardization ·Certification ·Agile
1 Motivation
In the energy and industry domain, vendor-independent scaling of distributed
systems is a key challenge. To provide interoperability between different systems
or integrated electronic devices (IED) the use of standardized communication
protocols (such as OPC UA [11], IEC 61850 [8], IEC 60870-5-104 [7], etc.) is
very common. While vendor independence is crucial for IEDs, which stay in
operation for years or decades, for IED vendors itself selling certified products
may also be a sales argument.
Test &
Certification
Implementation
Requirements Standard
Specification
Publishing
Standard
Conformance
Tests
Specification
Implementing
Test Suite
Standardization Process
Development & Certification Process
Requirements Design Operation
Fig. 1. Classic standardization and product development processes
S. Copei and M. Wickert—These two authors contributed equally.
c
The Author(s) 2020
M. Paasivaara and P. Kruchten (Eds.): XP 2020 Workshops, LNBIP 396, pp. 203–210, 2020.
https://doi.org/10.1007/978-3-030-58858-8_21
204 S. Copei et al.
Figure 1shows a classical standardization and certification scenario divided
into two processes. The first (upper) process shows a view on developing a new
version of a standard. The second process shows a classical waterfall model
for applications where the certification is part of the testing phase. Note, both
process views are very coarse overviews and do not provide a detailed look at a
certain complex standardization or certification scenario.
The standardization typically begins with the specification of standard doc-
uments for a collection of requirements. Usually, the communication standard
only describes the communication of a particular layer of the ISO/OSI commu-
nication stack. After publishing a finished version, conformance tests may be
specified, and test suites may be implemented. E.g. The OPC Foundation offers
a conformance test suite for its members [12]. The development of compliant
products and the certification of them are illustrated as a classical waterfall
model, where the certification is done in the test phase.
The key message of Fig. 1is that the development process typically starts
after (a new version of) the standard has been published. An earlier start of
software development may result in incompatibilities with the standard. From a
new requirement for the communication standard to a certified software version
in operation, it may easily take several years. E.g., the Protocol IEC 61850-1 was
published in 2003 in version 1.0 and 2013 in version 2.0. In the meantime, a lot of
extensions were developed e.g., [1,14]. From our practical experience with such
communication standards, we see a lot of vendor-specific deviations. Therefore
we assume that standardization approaches are often designed for classical and
not for agile development processes.
Smart Energy Applications and Industry 4.0, are connecting classical indus-
trial monitoring and control solutions with modern IoT-based technologies.
Thereby modern software development processes are applied to address fast-
changing requirements in both sectors to provide fast feedback cycles. Therefore
we reconsidered how standardization and certification processes can be inte-
grated into an agile product development process. It can be argued that stability
is an essential requirement for communication protocols. But from our experi-
ence with more than 15 different projects, we see an upcoming preference for
regular updates in operation over stability.
This paper presents two proposals to support agile standardization and cer-
tification processes. We propose a new standardization and certification process
for communication protocols. For both process, proposals will use the terms
standardization and certification. Our second proposal is an architecture for
cloud-native certification services. The aim of the architecture is to support our
idea of future agile certification processes. The proposals were developed with a
background in smart energy systems and industry 4.0. However, our aim was to
specify the process very generic to achieve transferability.
2 Related Work
Agile standardization and certification processes have already been examined
in various domains. Examples are high security system certification for aviation
Caas 205
[4] and railways [2]. The authors of [4] present a way to certify security-critical
components in a transportation system. They focus on high-level certificates. To
provide the credibility of the certificates, the authors use a semi-formal descrip-
tion language. [2] shows a way to certify security-critical aerospace components.
The authors use UML as a modeling tool to provide an incrementally changeable
model description to achieve an agile certification process. However, the solutions
presented in both papers are very domain-specific and focused on security certi-
fication. The given solutions only fit into their use cases and can not be used as a
general approach. Furthermore, the solutions only cover the certification process
on a client-side. Our solution wants to cover the whole process from developing
a standard to certifying implementations of it.
An evolutionary standardization approach for file-based data is presented
in [5]. The considered standardization focus is the engineering of automation
systems. The basic idea is to start from an existing proprietary file format of one
vendor and change it evolutionary to a neutral and later on to a common format,
apparently often XML in that context. Similar to our process, this approach
proposes a stepwise standardization. Nevertheless, the evolutionary approach is
not intended to support agile development processes and focuses on file-based
communication.
In [3] an agile standardization was performed for Process Control Equipment
(PCE). The domain is close to the considered domain of this work. The authors
require that standardization has to be done agile and “should proceed stepwise”.
However, the focus of [3] is the concrete standardization of PCE Requests, not
the standardization process itself.
3 The Agile Standardization and Certification Processes
Fig. 2. Agile standardization process
We propose an agile standardization and certification process that has two
intertwined development cycles, cf. Fig. 2. As in other agile approaches, standard-
ization and certification should be performed in small increments. The basic idea
is to start with a minimal set of communication protocol features (e.g., establish
206 S. Copei et al.
a connection or login to a server) and add feature by feature in several itera-
tions. Every iteration ends with a minor version change in the standard. The
corresponding part of the overall standard is published e.g., via Github or some
other configuration management service. Based on the publication of the stan-
dard for some features, the standard conformance tests that certify compliance
with these features are extended or adapted and again published via a config-
uration management service. The standardization process runs iteratively, i.e.,
as soon as one feature has been completed, subsequent application development
may start while the standardization continues with the next features.
The product development cycle, including the certification of a product, is
shown on the right side of Fig.2. The development of standard-compliant prod-
ucts may start with the requirements definitions for specific product features.
The implementation of these product features may follow this. As soon as some
feature is available, the feature implementation may try to pass the correspond-
ing protocol conformance tests for a specific communication standard version.
When the new product version is certified, it may be released and operated in
production.
Each time a new version of the standard is exposed, and the correspond-
ing conformance tests are deployed a test-driven development iteration of the
products is ready to begin. Obviously, the conformance test will not be able to
provide a complete test set for a product. However, these tests will support the
product development relating to the communication interfaces. This approach
has the advantage that first conformance tests will be available soon after the
first iterations of the standardization process have completed. Thus, product
development and standard development may be intertwined. Thereby, standard-
compliant products will be available soon after the standard has reached a suffi-
cient level of completeness. Besides, product development may provide feedback
to the standardization process. Product development may e.g, point to overly
complex conformance tests or inconvenient APIs or missing details, etc. This
feedback may be used by the standardization process to enhance the standard-
ization of the corresponding features and to come up with improved versions of
the conformance tests. The importance of such feedback is also discussed in [5].
On the other hand, new versions of the standard lead to changes in the con-
formance test. This may result in failing tests for the new standard version and
triggers the adaption of existing features. Such changes to already defined confor-
mance tests may also happen when following features or later standardization
iterations require previously standardized features to evolve. This is an infre-
quent problem inherent in agile software development. If a product development
team wants to avoid such issues, it may wait until the standardization process
has reached a sufficient level of completeness and stability. One can argue that
this may be a drawback of our approach since stability is a critical requirement
for communication devices in operation. However, since we have also to consider
security for such field devices, we have to provide easy mechanisms to provide
software updates in operation.
Caas 207
4 Certification as a Service Architecture
For a certain standard, a certification service will support the agile standardiza-
tion and certification process. Here we propose a microservice [6,10] based cer-
tification as a service architecture. This architecture should support the under-
standing of our agile standardization and certification process on the one hand.
An implementation of this architecture is currently work in progress and part of
our future work.
Repository Integration Certification Deployment
Product
Sources
Conformance
Tests Repository
Certification Body
Developer
Fig. 3. Continuous certification pipeline
Continuous integration and continuous deployment are methods to support
fast feedback during agile development. A Certification as a service implemen-
tation extends a typical continuous deployment pipeline, as shown in Fig.3.
The certification step should be performed after the integration phase (which
includes integration testing). The certification step consists of the execution of
the conformance tests and the creation of a certificate. An implementation of our
certification as a service platform will perform this step. This allows the deploy-
ment of certified products in every continuous deployment cycle. If conformance
tests fail, the pipeline stops at the certification step, just like a failure during
integration tests will stop the pipeline.
Each certification pipeline certifies a product according to a particular stan-
dard version. Whenever a new standard version is published, the respective con-
formance tests will be adapted or extended for this version of the standard. The
certification bodies will add the standard to a repository. As soon as the new
tests have uploaded, a product can be certified for the new standard version.
The certification service itself should be hosted as a service by the standard-
ization or depending on organizational aspects, a certification body. As software
as a service (SaaS), it should be compatible with a typical build pipeline software
such as Jenkins. That allows an independent certification of products even with
fast development cycles.
Our proposal for the certification service architecture is shown in Fig. 4.We
defined five microservices, two repositories, and an event broker.
The repositories are responsible for storing a product for certification (arti-
fact repository) and the conformance tests (conformance test repository). Both
artifacts and conformance tests should be available in different versions. To per-
form the conformance tests, an instance of the artifact should be up and run-
ning for certification. The “Artifact runner Service” is responsible for running
this artifact and configure it correctly. The “Test Service” will do the execution
208 S. Copei et al.
Conformance Test
Repository
Certification Service Architecture
Test Service
Certification Service
User Management
Artefact Runner Service
Billing Service
Event Broker
Artifact Repository
Fig. 4. Certification service architecture
of the conformance tests. It will also provide test results for the “Certification
Service”. The certification service will create a certificate for the artifact if all
tests are passed successfully. The “User Management” and “Billing Service” have
administrative responsibilities. Since the business model of a certification body
is to issue certificates, it is necessary to implement user management and billing
functionalities. The communication to the product development should be done
by RESTful HTTP, to integrate with existing build pipelines easily. For internal
communication, event sourcing should be used. Therefore we suggest making use
of an event broker like Apache Kafka.
Our architecture aims to provide a proposal for certification as a service solu-
tion. Typical container orchestration tools can support implementations. There-
fore an implementation of our service should be cloud-native [13].
5 Conclusion and Future Work
We presented a new way to achieve a more agile process during the standard-
ization and certification steps. We provide an architecture that should support
the affected stakeholders during the whole process. On the one hand, this means
that a standardization organization should have the possibility to provide fast
incremental updates of their standards. On the other hand, we enable com-
panies to use agile development processes for their certified implementation of
standardized communication interfaces.
In the next steps, we will implement the architecture for a new communica-
tion standard for e-mobility use cases. We will examine how agile standardiza-
tion approaches will work in that context. Furthermore, we will evaluate how
this approach will support the agile development of prototypes for e-mobility
use cases.
Caas 209
Acknowledgement and Disclaimer. This Publication is part of a
project [9] that has received funding from the European Union’s Hori-
zon 2020 research and innovation programme under grant agreement
N857237. The sole responsibility of this publication lies with the author. The European
Union is not responsible for any use that may be made of the information contained
therein.
References
1. Bergmann, J., Glomb, C., G¨otz, J., Heuer, J., Kuntschke, R., Winter, M.: Scalabil-
ity of smart grid protocols: protocols and their simulative evaluation for massively
distributed DERs. In: 2010 First IEEE International Conference on Smart Grid
Communications, pp. 131–136 (2010)
2. Bezzecchi, S., Crisafulli, P., Pichot, C., Wolff, B.: Making agile development
processes fit for V-style certification procedures. CoRR, abs/1905.06604 (2019).
arXiv:1905.06604
3. Bigvand, P.G., Drath, R., Scholz, A., Sculler, A.: Agile standardization by means
of PCE requests. In: 2015 IEEE 20th Conference on Emerging Technologies Factory
Automation (ETFA), pp. 1–8 (2015)
4. Coe, D.J., Kulick, J.H.: A model-based agile process for DO-178C certification.
In: Proceedings of the International Conference on Software Engineering Research
and Practice (SERP), p. 1. The Steering Committee of The World Congress in
Computer Science, Computer Engineering and Applied Computing (WorldComp)
(2013)
5. Drath, R., Barth, M.: Concept for managing multiple semantics with automationml
— maturity level concept of semantic standardization. In: Proceedings of 2012
IEEE 17th International Conference on Emerging Technologies Factory Automa-
tion (ETFA 2012), pp. 1–8 (2012)
6. Fowler, M., Lewis, J.: Microservices (2014). http://martinfowler.com/articles/
microservices.html
7. IEC 60870-5-104: Telecontrol equipment and systems. Standard, International
Electrotechnical Commission, Geneva, CH (2006)
8. IEC 61850 Standard Series: Communication networks and systems in substations.
Standard, International Electrotechnical Commission, Geneva, CH (2020)
9. Interconnect project - homepage. https://interconnectproject.eu/. Accessed 20 Apr
2020
10. Newman, S.: Building Microservices, 1st edn. O’Reilly Media Inc., Sebastopol
(2015)
11. OPC Unified Architecture, IEC 62541, Standard Series. Standard, OPC Founda-
tion, International Electrotechnical Commission, Scottsdale, USA (2008)
12. OPC foundation test tools. https://opcfoundation.org/developer-tools/certification-
test-tools/opc-ua- compliance-test-tool-uactt. Accessed 20 Apr 2020
13. Pahl, C., Jamshidi, P., Zimmermann, O.: Architectural principles for cloud soft-
ware. ACM Trans. Internet Technol. 18 (2017). https://doi.org/10.1145/3104028
14. Ustun, T.S., Ozansoy, C.R., Zayegh, A.: Implementing vehicle-to-grid (V2G) tech-
nology with IEC 61850-7-420. IEEE Trans. Smart Grid 4(2), 1180–1187 (2013)
210 S. Copei et al.
Open Access This chapter is licensed under the terms of the Creative Commons
Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/),
which permits use, sharing, adaptation, distribution and reproduction in any medium
or format, as long as you give appropriate credit to the original author(s) and the
source, provide a link to the Creative Commons license and indicate if changes were
made.
The images or other third party material in this chapter are included in the
chapter’s Creative Commons license, unless indicated otherwise in a credit line to the
material. If material is not included in the chapter’s Creative Commons license and
your intended use is not permitted by statutory regulation or exceeds the permitted
use, you will need to obtain permission directly from the copyright holder.
Article
Full-text available
Microservices is an emerging paradigm for developing distributed systems. With their widespread adoption, more and more work investigated the relation between microservices and security. Alas, the literature on this subject does not form a well-defined corpus : it is spread over many venues and composed of contributions mainly addressing specific scenarios or needs. In this work, we conduct a systematic review of the field, gathering 290 relevant publications—at the time of writing, the largest curated dataset on the topic. We analyse our dataset along two lines: (a) quantitatively, through publication metadata, which allows us to chart publication outlets, communities, approaches, and tackled issues; (b) qualitatively, through 20 research questions used to provide an aggregated overview of the literature and to spot gaps left open. We summarise our analyses in the conclusion in the form of a call for action to address the main open challenges.
Article
Full-text available
A cloud is a distributed Internet-based software system providing resources as tiered services. Through service-orientation and virtualization for resource provisioning, cloud applications can be deployed and managed dynamically. We discuss the building blocks of an architectural style for cloud-based software systems. We capture style-defining architectural principles and patterns for control-theoretic, model-based architectures for cloud software. While service-orientation is agreed upon in the form of service-oriented architecture and microservices, challenges resulting from multi-tiered, distributed and heterogeneous cloud architectures cause uncertainty that has not been sufficiently addressed. We define principles and patterns needed for effective development and operation of adaptive cloud-native systems.
Article
Full-text available
Electric Vehicles (EVs) have become very popular due to climate change concerns and carbon emission reduction schemes. Accordingly, in recent years the awareness of people about EVs has increased significantly. In addition to the well-known advantages such as cleaner environment, less oil-dependency, cheaper fuel, more silent operation etc., through smartgrids, EVs offer a unique benefit called vehicle to grid (V2G) technology. In order to define the role of EVs as distributed storage devices, simulation works undertaken in Paladin Designbase 4.0 are presented in this paper. It is shown that through V2G, EVs can support better operation of smartgrids in terms of reliability and storage. In order to achieve these, the components of smartgrids shall communicate and share information via communication lines. Having a universal communication standard is vital for implementing the plug-and-play concept in smartgrids. IEC 61850, the substation automation standard, could be used for this purpose. However, it is insufficient and must be expanded to cover missing links. In this paper, authors propose an extension to the IEC 61850-7-420 standard by defining the information model for controlling the charging and discharging of EVs.
Conference Paper
This contribution discusses the well-known paradox of today’s standardization approaches for semantic models in automation engineering and proposes an evolutionary concept to resolve it. In this context, an overview of past and current standardization activities is presented which points out the existing barriers. Instead of aiming for a completely standardized neutral data model, the proposed approach actively supports data exchange with mixed neutral and proprietary data models. Hence, it utilizes the existing heterogeneity and the maturity of proprietary data models. In this context, the authors present a concept of maturity levels, which form milestones towards a stepwise evolution of a semantic standardization. Finally, this paper describes how this approach is technically implemented in AutomationML and provides examples to illustrate the concept.
Conference Paper
Today, the whole energy sector is going to enter a phase of far-reaching revolution. The legacy power generation and transmission concept is converting to a massively distributed energy generation landscape integrating an extensive number of variable and small renewable energy resources such as biomass or PV installations with all their challenging effects on the energy grid. New stakeholders (e.g. energy resource aggregators), more flexibility for the consumers (energy market place), and totally new concepts (loading of e-Cars, usage of e-Cars as flexible power storage) have to be respected. Innovative monitoring and control concepts are required to operate these distributed energy resources in a reliable and safe way. This paper describes the principles for an efficient management of a massively distributed energy system based on small and variable energy resources. For evaluation purposes of this approach a newly developed coupled energy grid communication network simulator is introduced with which large scale aspects of the new ICT management frame¬works can be studied in a smart grid environment.
A model-based agile process for DO-178C certification
  • D J Coe
  • J H Kulick
Coe, D.J., Kulick, J.H.: A model-based agile process for DO-178C certification. In: Proceedings of the International Conference on Software Engineering Research and Practice (SERP), p. 1. The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing (WorldComp) (2013)
Making agile development processes fit for V-style certification procedures
  • S Bezzecchi
  • P Crisafulli
  • C Pichot
  • B Wolff
Bezzecchi, S., Crisafulli, P., Pichot, C., Wolff, B.: Making agile development processes fit for V-style certification procedures. CoRR, abs/1905.06604 (2019). arXiv:1905.06604
Building Microservices, 1st edn
  • S Newman
Newman, S.: Building Microservices, 1st edn. O'Reilly Media Inc., Sebastopol (2015)
IEC 60870-5-104: Telecontrol equipment and systems
IEC 60870-5-104: Telecontrol equipment and systems. Standard, International Electrotechnical Commission, Geneva, CH (2006)