This paper was converted on www.awesomepapers.org from LaTeX by an anonymous user.
Want to know more? Visit the Converter page.

Towards Reference Architectures for Trustworthy Collaborative Cyber-Physical Systems: Reference Architectures as Boundary Objects

Muhammad Rusyadi Ramli, Fredrik Asplund, and Martin Törngren Department of Machine Design
Mechatronics and Embedded Control Systems
KTH Royal Institute of Technology
Email: (ramli2, fasplund, martint)@kth.se
Abstract

This paper presents our work-in-progress study on reference architectures as boundary objects for realizing trustworthy collaborative Cyber-Physical Systems (CPS). Furthermore, the preliminary results from interviews with systems engineering experts from industry and academia are also discussed. The interview results reveal challenges in using reference architectures during the system development process. Furthermore, exactly which trustworthiness attributes (security, availability, reliability, etc.) should be addressed to realize trustworthy collaborative CPS is identified as an open question, which we will address in our future work.

Index Terms:
Reference architectures, stakeholders, collaborative CPS, trustworthiness, dependability.

I Introduction

In recent years, Cyber-physical Systems (CPS) has evolved to become more complex in the attempt to provide them with increasingly sophisticated capabilities [1]. This trend motivates industry and academia to investigate solutions to handle this increasing complexity. Many of today’s CPS applications are developed as collaborative systems in which the systems interact with other systems, forming systems-of-systems (SoS). SoS is commonly characterised by five principal features; operational independence, managerial independence, geographic distribution, evolutionary development, and emergent behavior [2]. Furthermore, the systems interact more with their environment. The systems may also work autonomously most of the time by relying on artificial intelligence (AI). These mentioned aspects provide new challenges for collaborative CPS, because their structure and behavior are exposed and could be influenced by external parties. In this paper we are mainly concerned with industrial CPS that are mission or safety critical. For such systems, it is a challenge to establish a trustworthy collaborative CPS (i.e. a CPSoS) that can ensure key properties such as safety and security, while also relying on AI to provide new functionalities and enhance performance.

The emergence of edge computing may have a major impact in expediting the development of collaborative CPS. The advancement of network devices (e.g., switch, router, bridge), embedded devices equipped with AI chips, telecommunication technology (5G), micro-services, containers, etc. make it feasible to support collaboration by computational tasks, data and models at the edge instead of the cloud [3]. Edge computing can reduce network latency compared to cloud computing due to its locality. Furthermore, edge computing can enable AI to bring its peak potential for collaborative CPS applications.

Trustworthiness is frequently raised as an essential aspect for future systems, and collaborative CPS is not the exception. Trustworthiness has for example been put forward from the perspectives of AI, human-machine interaction and CPS. Just like the concept of dependability, trustworthiness is an umbrella term. However, trustworthiness tends to be used as an even more multifaceted property, referring to qualities such as security, safety, and predictability [4] and a set of ethical properties, e.g., transparency and human oversight [5]. Nonetheless, the definition of trustworthiness and its attributes are still evolving. The broad scope of trustworthiness and the interdependencies (and trade-offs) between the involved qualities makes it difficult to determine proper trustworthiness attributes for realizing collaborative CPS. We believe that architecture guidelines represent one important means to improve on this situation. The architectural guidance can be used to ensure the trustworthiness attributes are addressed from the early process of system development.

Architectural guidance has a relation to all relevant stakeholders (e.g., business, consumer, and technical) involved in the development and integration of collaborative CPS. The need for architectural guidance becomes even more important with the increasing system complexity, shorter time-to-markets, and system development involving multiple teams and organizations [6]. Reference architectures have the purpose to provide such architectural guidance during the development of novel system architectures [7]. Reference architectures accomplish this by containing essential architectural patterns, the use of standards and often implicitly domain knowledge that constrains system design [7]. Therefore, reference architectures can be used to guide the alignment over the system and subsystem interactions and integration as well as help to integrate all stakeholders who are involved in the system development (in terms of establishing shared views of the same system).

In order to utilize the most of it, reference architectures should be able to provide the same architecture understanding to all stakeholders. For instance, the architect can communicate effectively with other architects or other stakeholders during the system development when they share the same architectural understanding. Furthermore, the work can be more efficient and flexible when the architects or other stakeholders recognize the same boundaries between functions, processes, and subsystems, speak the same language and use the same standards. This cooperation can moreover be achieved through the use of a common language, standards, viewpoints, and architecture patterns.

We are interested in the role and use of reference architectures for realizing trustworthy collaborative CPS. We consider intelligent transportation systems (ITS) as our main domain since it is well representative for collaborative CPS. Our research involves two steps; (1) studying how people and organizations understand and make use of reference architectures, and how they treat trustworthiness attributes when working with reference architectures, and (2) investigating how to represent knowledge, especially the trustworthiness attributes in the reference architecture. After conducting these two steps, we will summarize our research findings and prioritize follow up research, to be evaluated in an ITS setting. As part of our first step, we currently investigate the role of reference architecture as boundary objects for realizing trustworthy collaborative CPS.

II Related Works

The knowledge transfer plays an important role in the collaborative work environment where people with various backgrounds are involved. Nowadays, it is necessary for engineers to have a ”cross-boundary” skills to enable collaboration work effectively. Hence, there have been extensive studies focusing on knowledge transfer. For instance, [8] pointed that the knowledge transfer should be treated as a process in order to analyse it. The study therefore presented the process model of knowledge transfer. Furthermore, boundary spanning can be utilised as a useful method for knowledge transfer. As stated in [9], boundary spanning is the act of searching for knowledge from outside the current domain. Authors in [10] conducted a qualitative systematic review on boundary spanning and engineering.

In relation to knowledge transfer and development of CPS, [11] conducted a study on the viewpoints integration in the development of mechatronic products. In [12] investigated on how design contracts can facilitate the interaction between control and embedded software engineers for building CPS.

III Reference architecture as boundary object for trustworthy CPS

The organizations that develop a collaborative CPS, such as an ITS, typically strive to adopt systems engineering approaches to increase their work effectiveness. The organizations performing systems engineering can be conceived as a network of actors that have multiple goals. Also, they may use shared resources during the development process.

Boundary objects represent a concept for facilitating and enabling collaboration between various groups of actors (later we refer to such a group as a community of practice, CoP). There have been studies that investigate boundary objects in software and systems engineering. For instance, the study in [13] evaluated the use of reference architecture in the context of agile systems engineering in which the automotive domain is considered as the domain of study. [14] investigated architectural descriptions as boundary objects in systems engineering where they also specified the requirements for the creation of architectural descriptions. Recently, the study in [15] utilized reference architecture as boundary objects for the alignment of cross-domain stakeholders’ for the development of collaborative SoS. Unlike existing studies, we are focusing on how people in practices deal with trustworthiness attributes to create reference architectures for trustworthy collaborative CPS. In addition, The idea for this, came when coming across more and more proposed reference architectures e.g. in the context of Internet of things, smart CPS, etc., and noting that they tended to focus more or less entirely on functional aspects. Therefore, the reference architecture can be used as a practical boundary objects to align stakeholder’s ideas in realizing trustworthy collaborative CPS.

III-A Boundary objects theory

Star and Griesemer introduced the concept of boundary objects in 1989. They defined boundary objects as ”objects that are both plastic enough to adapt to local needs and the constraints of the several parties employing them, yet robust enough to maintain a common identity across sites” [16]. And these objects have different interpretations in different communities of practice (CoP). However, their structures are understandable enough to more than one community, thus making them recognizable through translation and interpretation [17]. Furthermore, these objects have different forms (e.g., physical or digital objects), and they carry information that can be implicit or explicit. For instance, the physical objects can be documents containing diagrams or descriptions of system architecture. Digital objects can be any documents in electronic form such as e-mail.

Objects become boundary objects when used at different CoP to transfer and share information without leaving the important context of information. CoP is a group where understanding, sense-making, and knowledge are shared across the people in the group [18]. For instance, a CoP has a shared understanding of what their community does and how they relate it to other communities and their practices. Essentially, boundary objects exist and are used at the interfaces between these CoPs.

III-B Challenges to realize trustworthy ITS

ITS are expected to contribute significantly to fostering road and traffic safety, energy efficiency, and reduced environmental pollution [19]. Trustworthiness attributes form essential requirements to address during the development of ITS. It is because most ITS tasks are dealing with safety-critical situations. Furthermore, some standards play a vital role for the ITS, particularly in the automotive domain, such as ISO 262626 [20] for ensuring the safety and ISO/SAE 21434 [21] for ensuring cybersecurity. However, proper guidance (e.g., reference architecture documentation) is still required to ensure trustworthiness attributes are addressed during system development.

ITS development processes involve collaboration between many stakeholders from various disciplines (e.g., software engineering, electronic engineering, mechanical engineering, economics, etc.). Thus, aside from the technical aspects the process of knowledge transfer also play an important role in developing a complex system such as ITS successfully. For instance, when designing software architecture of intelligent traffic lights, it may be a challenge to document and describe such a system so that key information, including context and rationale, can be shared effectively across organizational boundaries.

III-C Research method

We conducted our first round of interviews with systems engineering experts from industry and academia. In this round of interviews, we only considered systems engineer experts who have enough knowledge and experience in using reference architectures as our respondents. The purpose of the interviews is to study the concepts and practice related to reference architectures. Therefore, our research question is how do systems engineering experts perceive reference architectures?

In particular, we wanted to gather inputs on how the reference architectures for trustworthy CPS are perceived from a systems engineering perspective. We also wanted to collect information about the challenges of using reference architectures as well as what attributes should be captured to realize trustworthy systems.

III-D Survey questions

As mentioned previously, we focused on the concept and practice of reference architecture towards trustworthy collaborative CPS. The interview questions were as follows:

  • SQ1: What is the definition of reference architectures?

  • SQ2: Who are the intended users of reference architectures?

  • SQ3: How to design reference architectures?

  • SQ4: How to manage reference architectures?

  • SQ5: What aspect should be captured in the reference architecture for trustworthy collaborative CPS?

In the interview, we also asked our respondents about their personal information and experience related to systems engineering and reference architectures.

III-E Data collection

The respondents for the interview are five people, all having a background and strong experience in systems engineering. In particular, three of the respondents are working in industry and the rest are working in academia. In particular, our respondents from industry work in the domain of defense, control, and automotive. The interviews were conducted using a semi-structured approach. Each interview was performed for a one-hour duration. The respondents are aware that their answers may be used as part of research publications.

III-F Results and analysis

III-F1 Definition of reference architectures

We received similar responses about the definition of reference architectures from our respondents. They all agreed that reference architecture ”is a document” containing essential information (e.g., design patterns, standards). This information can be used to guide stakeholders during system development, for instance, for determining which design patterns that should be promoted or demoted. The reference architecture can also be used to guide system development in the future and make the process more effective.

In terms of systems management aspects, reference architectures enable cooperation across stakeholders to be more effective. It can solve the problems of sharing development resources. Reference architectures are also capable of creating consistency across distributed teams. One of our respondents pointed out that the use of reference architectures can increase the efficient use of personnel during the development process. The flow of personnel during the system development is dynamic, i.e., the project member may leave during the development process, and a new person comes. A reference architecture can be used as guidance to help this new member understand what is going on in the project.

III-F2 The intended users of reference architectures

We got valuable inputs from our respondents about the intended users of reference architectures. The intended users include all members who are involved in the development of systems. This response leads to the challenge of using reference architecture in practices. During the project, junior members sometimes may not understand the content of a reference architecture. In this case, they may come back to ask a chief engineer to get guidance. In order to utilize a reference architecture as a boundary objects, it is supposed to be understandable to all stakeholders. The solution may come by adding rationale in the reference architecture documentation to tackle this challenge. Another challenge is that the fact that the more diverse the group, the more challenging adoption is.

III-F3 Design reference architectures

In this aspect, the person who is responsible for designing reference architectures is the architect. The main reason is that the architects have the capability to capture information and design patterns. Capturing the patterns is a challenging task to conduct. However, it is sometimes challenging to capture tacit knowledge (implicit knowledge) from the people. For instance, it is difficult to get insight out of experienced people. Also, capturing past knowledge is challenging. As for the solution to capture the information, seminars or work-groups can be considered to capture the information. However, it needs particular ability to capture the implicit knowledge during the discussions. Furthermore, conceptual models (e.g., workflow, system partitioning) can be also considered to capture the information.

We also asked our respondents about transparency. Specifically, we asked whether transparency among stakeholders is essential for creating good documentation of reference architectures. We got a variety of responses, also influenced by the domain where our respondents work. Some domains are opaque in terms of giving information (e.g., defense and military). In practice, the architects must cope with the fact that there are boundaries between stakeholders. To capture the implicit information, then we need to reconstruct, guess, and find a way to validate it.

III-F4 Manage reference architectures

We also questioned our respondents on how to manage reference architectures to keep it ”alive” such that it can be used for the future system development. In this aspect, the reference architectures should not be updated too often. The reference architecture will be update only when it is necessary, such as the emergence of new technology or standards that are suitable for the systems. Another feedback was to avoid to use specific tools and only consider accessible tools such as the office tools to create a documentation of reference architectures.

III-F5 Trustworthiness attributes to realize trustworthy collaborative CPS

As mentioned previously, the terms of trustworthiness and its attributes are still somewhat unclear. Hence, we asked our respondents what they perceive as trustworthy systems and what attributes should be captured for trustworthy collaborative CPS. Our respondents had similar answers; they perceived trustworthy systems as similar to dependable systems and treat trustworthiness attributes as a set of qualities such as safety, security, reliability, etc. However, one open question remains whether the ethical aspects should be captured as essential attributes to realize trustworthy CPS. One main reason is that most of the collaborative CPS nowadays incorporate AI in various forms, so it would be reasonable to consider some ethical aspects of AI, such as explainability and respect for human autonomy.

IV Conclusion and future work

We have conducted interviews as part of our first step towards reference architectures for trustworthy collaborative CPS. The inputs we have obtained are helpful in guiding the next stage of our study. We have identified essential aspects that should be considered when designing reference architectures that can be used as effective boundary objects. In the next step, we will conduct interviews with industrial experts focusing on how industry deals with trustworthiness attributes when making use of reference architectures.

Acknowledgment

The authors acknowledge support from KTH based TECoSA research center (funded by Vinnova) and InSecTT ECSEL project. InSecTT (www.insectt.eu) has received funding from the ECSEL Joint Undertaking (JU) under grant agreement No 876038. The JU receives support from the European Union’s Horizon 2020 research and innovation programme and Austria, Sweden, Spain, Italy, France, Portugal, Ireland, Finland, Slovenia, Poland, Netherlands, Turkey. The document reflects only the author’s view and the Commission is not responsible for any use that may be made of the information it contains.

References

  • [1] M. Törngren and P. T. Grogan, “How to deal with the complexity of future cyber-physical systems?” Designs, vol. 2, no. 4, 2018.
  • [2] M. Maier, “Research challenges for systems-of-systems,” in 2005 IEEE International Conference on Systems, Man and Cybernetics, vol. 4, 2005, pp. 3149–3154.
  • [3] M. Caprolu, R. Di Pietro, F. Lombardi, and S. Raponi, “Edge computing perspectives: Architectures, technologies, and open security issues,” in 2019 IEEE International Conference on Edge Computing (EDGE), 2019, pp. 116–123.
  • [4] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic concepts and taxonomy of dependable and secure computing,” IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, pp. 11–33, 2004.
  • [5] High-Level Expert Group on AI of European Commission. (2019) Ethics guidelines for trustworthy ai. Brussels. [Online]. Available: https://ec.europa.eu/digital-single-market/en/news/ethics-guidelines-trustworthy-ai
  • [6] B. van der Sanden and A. Vasenev, “Architectural guidance in automotive for privacy and security: Survey and classification,” in 2020 IEEE International Systems Conference (SysCon), 2020, pp. 1–8.
  • [7] R. Cloutier, G. Muller, D. Verma, R. Nilchiani, E. Hole, and M. Bone, “The concept of reference architectures,” Syst. Eng., vol. 13, no. 1, p. 14–27, Feb. 2010.
  • [8] G. Szulanski, “The process of knowledge transfer: A diachronic analysis of stickiness,” Organizational Behavior and Human Decision Processes, vol. 82, no. 1, pp. 9–27, 2000.
  • [9] A. Nerkar and K. A. Miceli, Boundary Spanning.   London: Palgrave Macmillan UK, 2016, pp. 1–7.
  • [10] B. K. Jesiek, A. Mazzurco, N. T. Buswell, and J. D. Thompson, “Boundary spanning and engineering: A qualitative systematic review,” Journal of Engineering Education, vol. 107, no. 3, pp. 380–413, 2018.
  • [11] M. Törngren, A. Qamar, M. Biehl, F. Loiret, and J. El-khoury, “Integrating viewpoints in the development of mechatronic products,” Mechatronics, vol. 24, no. 7, pp. 745–762, 2014.
  • [12] P. Derler, E. A. Lee, M. Törngren, and S. Tripakis, “Cyber-physical system design contracts,” in 2013 ACM/IEEE International Conference on Cyber-Physical Systems (ICCPS), 2013, pp. 109–118.
  • [13] R. Wohlrab, P. Pelliccione, E. Knauss, and M. Larsson, “Boundary objects and their use in agile systems engineering,” Journal of Software: Evolution and Process, vol. 31, no. 5, p. e2166, 2019.
  • [14] L. Pareto, P. Eriksson, and S. Ehnebom, “Architectural descriptions as boundary objects in system and design work,” in Model Driven Engineering Languages and Systems, D. C. Petriu, N. Rouquette, and Ø. Haugen, Eds.   Berlin, Heidelberg: Springer Berlin Heidelberg, 2010, pp. 406–419.
  • [15] J. Kohlke, S. Hanna, and J. Schütz, “Cross-domain stakeholder-alignment in collaborative sos -lego® serious play® as a boundary object,” in 16th Annual Systems of Systems Engineering Conference, 06 2021.
  • [16] S. L. Star and J. R. Griesemer, “Institutional ecology, ‘translations’ and boundary objects: Amateurs and professionals in berkeley’s museum of vertebrate zoology, 1907-39,” Social Studies of Science, vol. 19, no. 3, pp. 387–420, 1989.
  • [17] A. Fong, R. Valerdi, and J. Srinivasan, “Boundary objects as a framework to understand the role of systems integrators,” Systems Research Forum, vol. 02, no. 01, pp. 11–18, 2007.
  • [18] J. S. Brown and P. Duguid, “Knowledge and organization: A social-practice perspective,” Organization Science, vol. 12, no. 2, pp. 198–213, 2001.
  • [19] T. Yuan, W. B. Da Rocha Neto, C. E. Rothenberg, K. Obraczka, C. Barakat, and T. Turletti, “Machine Learning for Next-Generation Intelligent Transportation Systems: A Survey,” Nov. 2020, working paper or preprint. [Online]. Available: https://hal.inria.fr/hal-02284820
  • [20] ISO. (2011) Road vehicles - functional safety. iso 262626:2011.
  • [21] ISO/SAE. (2020) Road vehicles - cybersecurity engineering. iso/sae 21434:2020.