Introduction

In recent years, embedded computing, wireless communication, sensor monitoring and large-scale data processing technologies have developed rapidly, which makes the computing process, communication process and physical process highly integrated. Computing ability, communication ability and perception ability are constantly integrated into the physical process, which makes the physical equipment be information and networked. This process forms a hybrid autonomous system, which is called Cyber-Physical System (CPS)1,2,3. At present, cyber-physical system is closely related to human life and social development, and has been applied to various fields, such as urban traffic flow forecasting4, smart grid control5, medical health management6, smart manufacturing7,] etc. Although they focus on different design goals and research contents, they essentially integrate and process the resources of physical space and information space through the network. It makes people’s life more convenient and comfortable.

From the system point of view, CPS is a large-scale multi-dimensional complex system based on physics. It has the following basic characteristics: scale diversity, space-time, distribution, dynamic reconfiguration, high autonomy, high reliability, strong security, etc8,9. In order to understand and explore these characteristics of this complex system, a highly abstract description method is usually needed to describe the system itself. As a highly abstract top-level design method, software architecture has been widely used. It is also suitable for the establishment of CPS model, so as to avoid getting caught up in tedious details too early, which makes it difficult to analyze the essential characteristics of the above system. At present, many scholars and researchers have explored CPS from the perspective of software architecture. For example, Ivanov et al.10 proposed an architecture for Cyber-Physical Systems (CPS) suitable for medical applications, which meets the requirements of rapid interrupt response and task switching. Vogel et al.11 have proposed a software architecture definition for Cyber-Physical Production Systems (CPPS) that aims to satisfy characteristics such as flexibility, maintainability, and extensibility. Dotty et al.12 have proposed a software architecture that can meet the requirements of intrusion detection and protection for CPS, thereby enhancing the security of CPS systems, and so on. Thus, software architecture is indispensable in CPS system. Excellent software architecture can not only make the design of CPS easier to meet user requirements, but also make CPS easier to extend, modify and maintain in the later period. This is one of the motives of this study. However, CPS does not remain unchanged after running. Faced with the change of user requirements and environment, CPS also needs to be changed accordingly. In addition, compared with the traditional information system, the CPS has more vigorous user requirements and more complex environment, so the CPS changes quite frequently. From the point of view of software architecture, the change of system is naturally reflected in the change of software architecture. The change of software architecture has always been the focus of attention in the field of software engineering. How to make the software architecture change correctly according to the change of requirement and environment is the second motive of this study.

Motivated by the software architecture of the cyber-physical system, the core concern objects of cyber-physical fusion are abstracted, adhering to the top-level design principle. Building on this foundation, the dynamic evolution process of CPS is explored, leading to the presentation of the following main contributions:

  1. (1)

    A unified mathematical model of a Bigraph for Cyber-Physical Systems (CPS) incorporating positional constraints is proposed. This model adopts a divide-and-conquer strategy, utilizing the link graph and the place graph of the Bigraph to represent the connectivity and positional relationships among various entities within the CPS, respectively.

  2. (2)

    A set of dynamic evolution rules for the architecture of CPS is designed. Based on these rules, a model for the dynamic evolution of CPS structure and information flow evolution is proposed through the idea of conditional matching and state transition.

  3. (3)

    Checking algorithms for consistency, integrity, and reachability constraints in the dynamic evolution of CPS architecture are designed based on the hypergraph characteristics of the link graph and the nested relationships of the place graph. These algorithms ensure the correctness and reliability of the CPS system after its dynamic evolution.

The rest of this paper is organized as follows: “Related work” section reviews the related work which includes traditional software system evolution and cyber-physical system modeling and evolution. “The basic concepts of CPS and Bigraph” section introductions the basic framework of CPS and Bigraph. “Architecture of cyber-physical systems” section details static and dynamic model of CPS. “Constraint analysis and checking algorithm design of architecture” section discusses constraint analysis and checking algorithm design of architecture. “Instance and experimental analysis” section carried out an instance and experiment to validate the proposed models and methods. “Conclusion” section gives the conclusion and the future directions of research.

Related work

Traditional software system evolution

Software system evolution is one of the research hotspots in the field of software engineering that has been continuously concerned. In recent years, it has been studied by many researchers from different perspectives and achieved a series of results, mainly focusing on three aspects: evolution rule description, software architecture evolution modeling, and evolution platform development.

In terms of evolution rule description, for instances, Ferchichi et al.13 analyzed the evolution process of software product line (SPL), proposed to use ontology to manage software evolution knowledge method, thus giving an ontology-based evolution rule description. Chaturvedi et al.14 analyzed system evolution through network graph model, and used subgraph transformation semantics to describe evolution rules, and implemented the corresponding prototype tool to verify the use of evolution rules. Berrio et al.15 used architecture description language to model service-oriented software architecture models, and used ADL to understand the evolution rules of components and connectors in software architecture. Chaturvedi et al.16 designed three types of labeled evolution rules for insertion, deletion, and modification within evolving cloud service systems. They conducted experiments on two cloud service systems to demonstrate the feasibility of these rules. Chaturvedi et al.17 also proposed methods for mining stable network evolution rules and metrics for variability within evolving systems over time, etc.

In terms of modeling software architecture evolution, for instances, Haitzer et al.18 used UML to model software architecture and discussed the consistency of software architecture evolution with source code evolution. Ivers et al.19 designed a search-based approach to software architecture refactoring evolution using optimization theory to guide the optimal model for refactoring evolution. Zhong et al.20 constructed an inverse model of software architecture using binary tree as a way to support the construction of software evolution. Chaturvedi et al.21 have proposed an Evolution and Change Learning (ECL) method, which combines evolution with neural networks to develop a system structure learning algorithm, making it possible for intelligent evolutionary analysis, etc.

In terms of evolution platform development, for instances, Ali et al.22 develop a Repast software dynamic evolution simulation environment, which is a dynamic evolution simulation model for agents that better reflects the real world of software evolution compared to the traditional system dynamic evolution simulation model SD. Cui et al.23 designed a dynamic wearable computer software platform based on the cloud computing platform and developed a corresponding graphical management interface for wearable computers. Chaturvedi24 generates evolution information of call graphs among various versions of a software system within a graph-based environment, thereby supporting software evolution analysis and facilitating the maintenance or upgrade process of the software system, etc.

Although the current field of software system evolution has achieved good research results in these areas, the special nature of the physical properties of cyber-physical systems makes it impossible to apply them directly to the evolution of such systems, and new evolutionary techniques are needed to support them.

Cyber-physical system modeling and evolution

Cyber-physical systems are an extension of traditional software systems to the physical world, which are different from the construction and composition of traditional software systems. The integration of information space and physical space makes the evolution of such systems more complex. Traditional software system evolution methods mainly focus on the modeling and analysis of information space evolution, which are not suitable for cyber-physical system evolution modeling and analysis. This is because they lack the capability of describing the physical space, that is, they do not have the ability to describe both the information space and the physical space at the same time. The modeling of cyber-physical systems is challenging due to their dual-space attribute. However, in recent years, many researchers have explored in two aspects: cyber-physical system modeling and cyber-physical system evolution analysis.

Cyber-physical system modeling aims to model the structure or behavior of the cyber-physical system, without considering the dynamics of its structural or behavioral changes. It employs formal modeling methods such as AADL, UML, Petri net, multi-paradigm, etc. For instance, Zhang et al.25 developed an extended AADL based on Modelica and cellular automata to model cyber-physical systems, and demonstrated the effectiveness of this modeling approach with concrete examples. Ionita et al.26 analyzed how to use UML for modeling Cyber-Physical Systems (CPS) and discussed UML along with two of its parts particularly relevant in the context of CPS applications: SysML and MARTE. Grobelna et al.27 utilized interpreted Petri nets to describe cyber-physical systems and characterize the behavior of concurrent processes within these systems. Morozov et al.28 applied a multi-paradigm modeling MPM method for modeling cyber-physical systems, thereby improving the interoperability of the system, etc.

The evolution analysis of cyber-physical systems mainly involves modeling and analyzing the changes in system structure and behavior. Some researchers have also begun to explore this topic in recent years. For instance, Lehnert et al.29 proposed a method for describing automation software variants in Cyber-Physical Production Systems (CPPS) based on a Domain-Specific Language (DSL). This method models the evolution of system software by utilizing multiple levels of abstraction. Haubeck et al.30 focused on the evolution of cyber-physical production systems CPPS, and emphasized the capability of machine evolution awareness. They introduced a concept of machine evolution community to support the identification and propagation of different evolution use cases. Yu et al.31 adopted generalized stochastic Petri nets to present a dynamic model of malware system propagation. Based on this model, they developed a trustworthy evolution model of cyber-physical manufacturing system CPMS, and demonstrated the validity of their approach through simulation experiments. Dong et al.32 developed a hierarchical evolution model of spatial power grid, and examined the fragility of the structure under global and local failures, etc. Moreover, some researchers utilized dynamic update techniques to the evolution update of cyber-physical systems. For instance, Gartziandia et al.33 addressed the challenge of detecting runtime performance issues when deploying new software versions for microservices, and suggested a machine learning-based algorithm that forecasts the performance of new versions based on the knowledge of previous versions, to guarantee the reliability of cyber-physical system updates. Houssem et al.34 present an evolutionary process for cyber-physical system product lines that leverages contract-based design (CBD) to enable reuse of components and incremental analysis and verification of their modules. Stadler et al.35 introduce a runtime model GRuM that supports updating and adapting cyber-physical systems as they evolve. Vierhauser et al.36 propose a novel framework for runtime monitoring of cyber-physical systems that combines model-driven and runtime monitoring techniques to enhance maintenance efficiency by tracking system evolution. Zimmermann et al.37 proposed a graph-based Cyber-Physical System architecture that can improve change impact analysis and track the interrelationships between system elements and their digital representations, etc.

From the perspective of formal modeling methods, AADL, UML, Petri nets, multi-paradigm, graphs, hypergraphs, and other formal modeling methods currently focus on modeling the single information space of cyber-physical systems, and these methods only have the ability to model in a single dimension. However, the physical space of cyber-physical systems is also an extremely important part, and the loss of modeling for this part of the evolution makes it difficult to effectively analyze the evolution of the entire system. From the perspective of structural and behavioral evolutionary modeling analysis methods, these methods also tend to model the structure and behavior of information space, without simultaneously conducting structural and behavioral modeling analysis research in both information space and physical space. In other words, these studies have only explored one aspect of evolution, and have not provided a systematic and in-depth approach to modeling and analysis from both perspectives. This is the motivation behind this study. The proposed Bigraph method can tackle the challenge of concurrently modeling both the information space and the physical space.

The basic concepts of CPS and bigraph

The basic framework of CPS

Fig. 1
Fig. 1
Full size image

The basic framework of cyber-physical systems.

Cyber-physical systems highlight the interaction between the physical world and the information world, as shown in Fig. 1. The system consists of a sensor network that can perceive the physical environment, an information world platform that processes the physical attribute information obtained by the sensor network, a controller network that obtains the relevant control information after computation, and an actuator network that receives the control information and performs various actions to change the related attributes of the physical world. Through this iterative process, the system meets the desired needs of people. Thus, cyber-physical systems emphasize the fusion of physical and information, enabling the integration and coordination of the physical world and the virtual world, and creating the next generation of intelligent systems that can autonomously sense, predict, plan and adjust. Traditional software systems are mainly described by means such as ADL, process algebra, graphs, Petri nets, etc. However, they only account for the information world and neglect the physical world, making them inadequate for describing and characterizing cyber-physical systems. Fortunately, Turing Award winner Milner38 proposed a Bigraph model that can describe both the physical world and the information world for ubiquitous computing. Bigraph is well suited for representing cyber-physical systems and will be explained in more detail below.

Bigraph

  1. (1)

    Bigraph static semantics.

Bigraph is composed of a place graph and a link graph, denoted as B=(BP, BL)= (V, E, Ctrl, Prnt, Link): < m,X>→< n,Y>. The place graph is BP=(V, Ctrl, Prnt): m→n. The link graph is BL=(V, E, Ctrl, Link): X→Y. V denotes a finite set of nodes. E denotes a finite set of edges. Ctrl: V→K denotes a mapping graph from node V to control K, that is, the type of node V is K, and K has three states: active, inactive and atomic. Prnt: m\(\:\uplus\:\)v→v\(\:\uplus\:\)n denotes a parent mapping, which is a non-cyclic graph, consisting of n trees forming a forest, where the names of the n outer domains indicate the roots of the n trees. Link: X\(\:\uplus\:\)P→E\(\:\uplus\:\)Y denotes a link mapping graph, P={(v, i)|i \(\in\) mp(Ctrl(v))} denotes the set of ports of all nodes of B, that is, (v,i) represents the i-th port of node v. The m denotes the number of inner sites. X denotes the set of inner names. The n denotes the number of outer domains. Y denotes the set of outer names. Figure 2 shows a Bigraph, and Figs. 3 and 4 show its place graph and link graph respectively.

Fig. 2
Fig. 2
Full size image

Bigraph.

Fig. 3
Fig. 3
Full size image

Place graph.

Fig. 4
Fig. 4
Full size image

Link graph.

As shown above, Bigraph is a graphical modeling method that allows observation, but it is not suitable for computer systems to understand and process. Therefore, Minler et al.38 also introduced a term language in its algebraic form to formally reason and deduce the relevant properties of the system. The meanings of the terms and operations in the term language are shown in Table 1.

  1. (2)

    Bigraph dynamic semantics.

Bigraph can also characterize the dynamics of the model. Its main idea is to use a reaction rule to transform Bigraph B into Bigraph B’. This transformation process is also known as the reaction system of Bigraph. Figure 5 shows an example of a reaction system. In a local service center L-Center, there is data D on a data server LocalS. For security purposes, the data D on the local server LocalS is remotely backed up to a cloud server CloudS1 in the cloud service. This operation is achieved by a reaction rule \(\:(r,{r}_{\:}^{{\prime\:}})\), which is a substitution process of a pair of subgraphs, as shown in Fig. 6. The r is the left-hand side subgraph, and \(\:{r}_{\:}^{{\prime\:}}\) is the right-hand side subgraph. That is, in the main graph, find and replace the matching left-hand side subgraph r with the right-hand side subgraph \(\:{r}_{\:}^{{\prime\:}}\). The rest of the main graph remains unchanged after the reaction. For more details about Bigraph and its dynamic semantics, please refer to literature38.

Fig. 5
Fig. 5
Full size image

Reaction system.

Fig. 6
Fig. 6
Full size image

Reaction rule.

Table 1 The term meaning of bigraph.

Architecture of cyber-physical systems

Static model of CPS

System architecture is a high-level abstraction that captures the essence of a system, typically composed of three parts: components, connectors, and constraints. It helps to avoid getting bogged down in tedious details too early when conducting evolutionary analysis on a system, and facilitates studying the system’s structure and behavior from a macro perspective. Cyber-physical systems are an extension of traditional information systems, which link the physical world with the information world through networks to enable interaction. However, due to the openness, freedom, and difficulty of controlling the physical environment, such systems require more design and analysis of their structure and behavior essence from the system architecture level. From the system architecture perspective, the first step is to abstract out the essential components in cyber-physical systems, mainly including environment entities, sensor entities, controller entities, actuator entities, information entities, and environmental places, and provide their definitions.

Definition 1

(Environment Entity): An environment entity is an object or person that can be perceived in the physical world, with its own unique identity and physical attributes. Formally, it can be represented by a triple M = (IDM, KM, AttrM), where IDM denotes the identity identifier of the environment entity, and KM denotes the control type of the environment entity, AttrM represents the control attributes of environment entities. It usually has three types: active, inactive and atomic. Active representations can use reaction rules for it, inactive representations cannot use reaction rules for it, and atomic representations cannot be nested.

Definition 2

(Sensor Entity): A sensor entity is an entity that perceives the information of environment entities in a cyber-physical system. Formally, it can be represented by a triple S = (IDS, KS, AttrS), where IDS denotes the identity identifier of sensor entities, KS denotes the control type of sensor entities, AttrS denotes the control attributes of sensor entities. It usually has three types: active, inactive and atomic. Active means that the sensor is in sleep mode and can apply reaction rules. Inactive means that the sensor is in work mode and cannot apply reaction rules. Atomic means that the sensor cannot be nested but can apply reaction rules.

Definition 3

(Controller Entity): A controller entity is an entity that controls the information flow between environment entities and sensors in a cyber-physical system. Formally, it can be represented by a triple C = (IDC, KC, AttrC), where IDC denotes the identity identifier of the controller entity, KC denotes the control type of the controller entity, AttrC denotes the control attribute of the controller entity. It usually has three types: active, inactive and atomic. Active means that the controller is in sleep mode and can apply reaction rules. Inactive means that the controller is in work mode and cannot apply reaction rules. Atomic means that the controller cannot be nested but can apply reaction rules.

Definition 4

(Actuator Entity): An actuator entity is an entity that executes the information from controller entities a cyber-physical system. Formally, it can be represented by a triple A = (IDA, KA, AttrA), where IDA denotes the identity identifier of the actuator entity, KA denotes the type of control that the actuator entity belongs to, AttrA denotes the control attributes of the actuator entity. It usually has three types: active, inactive and atomic. Active means that the actuator is in sleep mode and can apply reaction rules. Inactive means that the actuator is in work mode and cannot apply reaction rules. Atomic means that the actuator cannot be nested but can apply reaction rules.

Definition 5

(Information Entity): An information entity is a data entity in a sensor entity, a controller entity, or an actuator entity of a cyber-physical system. Formally, it can be represented by a triple I = (IDI, KI, AttrI), where IDI denotes the identity identifier of the information entity, KI denotes the control type of the information entity, AttrI denotes the control attribute of the information entity, which is usually atomic.

Definition 6

(Environment Place Entity): In cyber-physical system, the entity that is used to assign the location area of environment entity, sensor entity, controller entity, actuator entity and information entity is called environment place entity. Formally, it can be represented by a triple D = (IDD, KD, AttrD), where IDD denotes the identity identifier of the environment place, KD denotes the control type of the place, AttrD denotes the control attribute of the environment place. It usually has three types: active, inactive and atomic. Active means that reaction rules can be applied to the environment place entity. Inactive means that reaction rules cannot be applied to the environment place entity. Atomic means that it cannot be nested but reaction rules can be applied to it.

In order to more clearly demonstrate the control over various entities within the system structure, Table 2 summarizes the control types and control attributes corresponding to the entities defined above.

Table 2 Control set of entities.

Definition 7

(Bigraph Model of Architecture of Cyber-Physical System): It is a Bigraph structure composed of environment entities, sensor entities, controller entities, actuator entities, information entities and environment place entities according to some constraint rules. Formally, it can be represented by a six tuples CPSSA = (V, D, I, E, Prnt, Link), where V=(M, S, C, A), M is environment entity set, S is sensor entity set, C is controller entity set, A is actuator entity set. D is the entity set of environment place. I is the information entity set. E is the edge set of V. Prnt is a set of mapping relations between D and I to entity V, indicating the location area of V and the dependent entity of I, i.e. Prnt: D\(\:\to\:\)V; Link is a set of mapping relations between V entity and V entity, i.e. Link: V\(\:\to\:\)V.

Specifically, as shown in Table 3, there is a well-established mapping relationship between the architecture of CPS and Bigraph.

Table 3 The mapping relationship between architecture of CPS and bigraph.

Dynamic model of CPS

Computer information systems are constantly evolving in response to the changing requirements and environment. Cyber-physical system is a kind of extension of traditional computer information system, and it also undergoes evolution under the influence of requirements and environment. This process of change is called system evolution. System evolution is not a disorderly process, it usually follows certain rules. Evolution rules usually have three operations: adding, replacing and deleting. However, the three traditional evolutionary rules only describe the link relations of adding, replacing and deleting entities, and do not pay attention to the place relations of these entities. This paper focuses on the simultaneous link and place relationships involving the addition, replacement, and deletion of entities, with the relevant rules described below.

Definition 8

(Entity Adding Rule): In CPS, when the adding entity is one of environment entity M, sensor entity S, controller entity C and actuator entity A, the rule is r1:\(\:\left\{\begin{array}{c}{D(U}_{X})\to\:D({U}_{X}\left|{V}_{Y}\right)\\\:{e/}_{\varnothing\:,\varnothing\:}\to\:{e/}_{X,Y}\end{array}\right.\), as shown in Fig. 7. D denotes an environment place entity, which is used to determine the specific place of the adding entity. U\(\:\in\:\){M, S, C, A}. V denotes an adding entity and V\(\:\in\:\){M, S, C, A}. The e denotes the edge. X and Y denote ports. \(\:\varnothing\:\) denotes empty port. The left part of \(\:\to\:\)denotes the entity place and link relation before evolution. The right part of \(\:\to\:\) denotes the entity place and link relation after evolution. When the adding entity is environment place entity D, and the rule is r2: \(\:{D}_{1}\to\:{D}_{1}\left|\right|{D}_{2}\), as shown in Fig. 8. Where D2 is an adding environment place entity, without considering edges. When the adding entity is information entity I, and the rule is r3: \(\:U\to\:U\left(V\right)\), as shown in Fig. 9. Where U\(\:\in\:\){M, S, C, A}, V denotes an adding information entity I, without considering edges.

Fig. 7
Fig. 7
Full size image

Rule r1.

Fig. 8
Fig. 8
Full size image

Rule r2.

Fig. 9
Fig. 9
Full size image

Rule r3.

Definition 9

(Entity Replacing Rule): In CPS, when the replacing entity is one of environment entity M, sensor entity S, controller entity C and actuator entity A, the rule is r4:\(\:\left\{\begin{array}{c}{D(U}_{X}\left|{V}_{Y}\right)\to\:{D(U}_{X}\left|{V}_{Z}^{{\prime\:}}\right)\\\:{e/}_{X,Y}\to\:{e/}_{X,Z}\end{array}\right.\), as shown in Fig. 10. D denotes an environment place entity, which is used to determine the specific place of the replacing entity. U\(\:\in\:\){M, S, C, A}. V denotes an before replacing entity and V\(\:\in\:\){M, S, C, A}. \(\:{V}_{\:}^{{\prime\:}}\) denotes an after replacing entity and \(\:{V}_{\:}^{{\prime\:}}\in\:\){M, S, C, A}. The e denotes the edge. X, Y and Z denote ports. The left part of \(\:\to\:\) denotes the entity place and link relation before evolution. The right part of \(\:\to\:\)denotes the entity place and link relation after evolution. When the replacing entity is environment place entity D, and the rule is r5: \(\:{D}_{1}\left|\right|{D}_{2}\to\:{D}_{1}\left|\right|{D}_{2}^{{\prime\:}}\), as shown in Fig. 11. Where D1 is a before replacing environment place entity, D2 is an after replacing environment place entity, without considering edges. When the replacing entity is information entity I, and the rule is r6: \(\:U\left(V\right)\to\:U\left({V}_{\:}^{{\prime\:}}\right)\), as shown in Fig. 12. Where U\(\:\in\:\){M, S, C, A}, V is a before replacing information entity, \(\:{V}_{\:}^{{\prime\:}}\) is an after replacing information entity, without considering edges.

Fig. 10
Fig. 10
Full size image

Rule r4.

Fig. 11
Fig. 11
Full size image

Rule r5.

Fig. 12
Fig. 12
Full size image

Rule r6.

Definition 10

(Entity Deleting Rule): In CPS, when the deleting entity is one of environment entity M, sensor entity S, controller entity C and actuator entity A, the rule is r7:\(\:\left\{\begin{array}{c}{D(U}_{X}\left|{V}_{Y}\right)\to\:D\left({U}_{X}\right)\\\:{e/}_{X,Y}\to\:{e/}_{\varnothing\:,\varnothing\:}\end{array}\right.\), as shown in Fig. 13. D denotes an environment place entity, which is used to determine the specific place of the deleting entity. U\(\:\in\:\){M, S, C, A}. V denotes an deleting entity and V\(\:\in\:\){M, S, C, A}. e denotes the edge. X and Y denote ports. \(\:\varnothing\:\) denotes empty port. The left part of \(\:\to\:\) denotes the entity place and link relation before evolution. The right part of \(\:\to\:\) denotes the entity place and link relation after evolution. When the deleting entity is environment place entity D, and the rule is r8: \(\:{D}_{1}\left|\right|{D}_{2}\to\:{D}_{1}\), as shown in Fig. 14. Where D2 is a deleting environment place entity, without considering edges. When the deleting entity is information entity I, and the rule is r9: \(\:U\left(V\right)\to\:U\), as shown in Fig. 15.Where U\(\:\in\:\){M, S, C, A}, V denotes an deleting information entity I, without considering edges.

Fig. 13
Fig. 13
Full size image

Rule r7.

Fig. 14
Fig. 14
Full size image

Rule r8.

Fig. 15
Fig. 15
Full size image

Rule r9.

Definition 11

(CPS entity evolution): CPS entity evolution is the process of changing the system to adapt to the evolving requirements by adding, replacing and deleting rules in CPS. Formally, suppose there are Bigraph B0 and target Bigraph Bn, and the set of evolution rules R = { r1, r2, r4, r5, r7, r8}, the process of B0 evolving into Bn is B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)Bn−1\(\:\underrightarrow{{r}_{n}}\) Bn, where ri\(\:\in\:\)R, n\(\:\in\:{N}^{*}\), Bi is the intermediate state.

Proposition 1

Suppose there are an initial Bigraph B0 of CPS and a target Bigraph Bn. In target Bigraph, only environment entity M, sensor entity S, controller entity C, actuator entity A and environment place entity D are evolved, so initial Bigraph B0 can always be transformed into target Bigraph Bn by using rule R = {r1, r2, r4, r5, r7, r8} for a limited number of times.

Proof 1

(1) When n = 1, the target Bigraph is B1. It is known that the transformation from B0 to B1 involves only the addition, deletion, or replacement of entities M, S, C, A, and any ri\(\:\in\:\)R represents a Bigraph transformation rule, which is an atomic operation for the addition, deletion, or replacement of M, S, C, A in Bigraph transformation. B1 is obviously obtained from B0 using one of these ri transformations, i.e., B0 \(\:\underrightarrow{{r}_{i}}\) B1 holds.

(2) Suppose that when n = k, B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)Bk−1\(\:\underrightarrow{{r}_{k}}\) Bk holds. Similarly to B0 \(\:\underrightarrow{{r}_{i}}\) B1, any Bi−1 \(\:\underrightarrow{{r}_{i}}\) Bi also holds. When n = k + 1, B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)Bk\(\:\underrightarrow{{r}_{k+1}}\) Bk+1 can be transformed into B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)B(k+1)−1\(\:\underrightarrow{{r}_{k+1}}\) Bk+1.Therefore, when n = k+1, B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)Bk\(\:\underrightarrow{{r}_{k+1}}\) Bk+1 holds, meaning that any Bi−1 \(\:\underrightarrow{{r}_{i}}\) Bi also holds.

From (1) and (2), it can be concluded that the proposition holds for all positive integers n\(\:\in\:{N}^{*}\).

Definition 12

(Evolution of CPS Information Flow): In CPS, information is constantly added, replaced and deleted in the environment entity M, the sensor entity S, the controller entity C and the actuator entity A. This process is called information flow evolution. Formally, suppose there are Bigraph B0 and target Bigraph Bn, and the set of evolution rules \(\:{R}_{\:}^{{\prime\:}}\) = {r3, r6, r9 },the process of B0 g into Bn by information flow evolved is B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)Bn−1\(\:\underrightarrow{{r}_{n}}\) Bn, where ri\(\:\in\:{R}_{\:}^{{\prime\:}}\), \(\:n\in\:{N}^{*}\), Bi is the intermediate state.

Proposition 2

Suppose there are an initial Bigraph B0 and a target Bigraph Bn of CPS. In target Bigraph, only information entity I is evolved, so initial Bigraph B0 can always be transformed into target Bigraph Bn by using rule \(\:{R}_{\:}^{{\prime\:}}\) = {r3, r6, r9} for a limited number of times.

Proof 2

(1) When n = 1, the target Bigraph is B1. It is known that the transformation from B0 to B1 involves only the addition, deletion, or replacement of information entities I, and any ri\(\:\in\:{R}_{\:}^{{\prime\:}}\) represents a Bigraph transformation rule, which is an atomic operation for the addition, deletion, or replacement of I in Bigraph transformation. B1 is obviously obtained from B0 using one of these ri transformations, i.e., B0 \(\:\underrightarrow{{r}_{i}}\) B1 holds.

(2) Suppose that when n = k, B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)Bk−1\(\:\underrightarrow{{r}_{k}}\) Bk holds. Similarly to B0 \(\:\underrightarrow{{r}_{i}}\) B1, any Bi−1 \(\:\underrightarrow{{r}_{i}}\) Bi also holds. When n = k + 1, B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)Bk\(\:\underrightarrow{{r}_{k+1}}\) Bk+1 can be transformed into B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)B(k+1)−1\(\:\underrightarrow{{r}_{k+1}}\) Bk+1.Therefore, when n = k+1, B0 \(\:\underrightarrow{{r}_{1}}\) B1\(\:\underrightarrow{{r}_{2}}\) B2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\)Bk\(\:\underrightarrow{{r}_{k+1}}\) Bk+1 holds, meaning that any Bi−1 \(\:\underrightarrow{{r}_{i}}\) Bi also holds.

From (1) and (2), it can be concluded that the proposition holds for all positive integers n\(\:\in\:{N}^{*}\).

Proposition 3

Suppose there are an initial Bigraph B0 and a target Bigraph Bn of CPS. Regardless of which entity is evolved in Bn, the initial Bigraph B0 can always be transformed into the target Bigraph Bn by using the rules R = { r1, r2, r4, r5, r7, r8} and \(\:{R}_{\:}^{{\prime\:}}\) = { r3, r6, r9 } for a limited number of times.

Proof 3

Based on propositions 1 and 2, and with reference to proof 1 and proof 2, proposition 3 is true.

Definition 13

(CPS evolution Model): Assuming a CPS (Cyber-Physical System) architecture is described as CPSSA=(V, D, I, E, Prnt, Link) using Bigraph, and nine evolution rules, r1 to r9, are defined on this structure, when CPSSA evolves into a desired CPSSA driven by this set of rules, then the comprehensive model of CPS evolution is described as CPSSA0 \(\:\underrightarrow{{r}_{1}}\) CPSSA1\(\:\underrightarrow{{r}_{2}}\) CPSSA2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\) CPSSAn−1\(\:\underrightarrow{{r}_{n}}\) CPSSAn. Where V=(M, S, C, A), M is environment entity set, S is sensor entity set, C is controller entity set, A is actuator entity set. D is the entity set of environment place. I is the information entity set. E is the edge set of V. Prnt is a set of mapping relations between D and I to entity V, indicating the location area of V and the dependent entity of I, i.e. Prnt: D\(\:\to\:\)V; Link is a set of mapping relations between V entity and V entity, i.e. Link: V\(\:\to\:\)V. Evolution rule ri is one of the evolution rules specified in Definition 8, Definition 9, and Definition 10.

Constraint analysis and checking algorithm design of architecture

Architecture as a high-level abstract description of a system, its changes are not arbitrary, it always has to conform to pre-agreed constraints. From the overall structure, these constraints mainly involve consistency, integrity and accessibility constraints.

Definition 14

(Consistency of CPS Dynamic Evolution): After the dynamic evolution of CPS, if all environment entities M are linked to sensor entities S, all sensor entities S are linked to controller entities C, all controller entities C are linked to actuator entities A, all actuator entities A are linked to environment entities M, and all information entities I are placed only one of sensor entities S, controller entities C or actuator entities A, the dynamic evolution of CPS is consistent. Formally, in CPSSA, if \(\:\forall\:{M}_{X}\), \(\:\exists\:{S}_{Y}\), \(\:\exists\:{\text{e}/}_{X,Y}\), and if \(\:\forall\:{S}_{X}\), \(\:\exists\:{C}_{Y}\), \(\:\exists\:{\text{e}/}_{X,Y}\), and if \(\:\forall\:{C}_{X}\), \(\:\exists\:{A}_{Y}\), \(\:\exists\:{\text{e}/}_{X,Y}\), and if \(\:\forall\:{A}_{X}\), \(\:\exists\:{M}_{Y}\), \(\:\exists\:{\text{e}/}_{X,Y}\), and if \(\:\forall\:I\), \(\:\exists\:\)S(I), or \(\:\exists\:\)C(I), or \(\:\exists\:\)A(I), then CPSSA\(\:\)Const, where X and Y denote port, Const denotes consistency, \(\:\)denotes that it satisfies some property.

Definition 15

(Integrity of CPS Dynamic Evolution): After the dynamic evolution of CPS, if the number of sensor entities S in an environment place entity D is required to be no less than m, the number of one controller entity C link sensor entity S is required to be no more than n, the number of one controller entity C link actuator entity S is required to be no more than k, the dynamic evolution of CPS owns integrity. Formally, in CPSSA, if \(\:\forall\:\)D, \(\:\exists\:\){D(S1), D(S2), …, D(Sp)}, p\(\:\ge\:\)m, and if \(\:\forall\:\)CX, \(\:\exists\:\){\(\:{S}_{Y1}^{1}\), \(\:{S}_{Y2}^{2}\), …, \(\:{S}_{Yp}^{p}\)}, {\(\:{\text{e}/}_{X,Y1}\), \(\:{\text{e}/}_{X,Y2}\),…., \(\:{\text{e}/}_{X,Yp}\)}, p\(\:\le\:\)n, and if \(\:\forall\:\)CX, \(\:\exists\:\){\(\:{A}_{Y1}^{1}\), \(\:{A}_{Y2}^{2}\), …, \(\:{A}_{Yt}^{p}\)}, {\(\:{\text{e}/}_{X,Y1}\), \(\:{\text{e}/}_{X,Y2}\), …., \(\:{\text{e}/}_{X,\text{Y}t}\)}, t\(\:\le\:\)k, then CPSSA\(\:\)Inte, where X and Y denote port, Inte denotes integrity, \(\:\)denotes that it satisfies some property.

Definition 16

(Reachability of CPS Dynamic Evolution): After the dynamic evolution of CPS, if they start from any environment entity M, it can always reach the actuator entity A through sensor entity S and controller entity C, the dynamic evolution of CPS is reachable. Formally, in CPSSA, if \(\:\forall\:\)M, \(\:\exists\:\)Path: MX1\(\:\underrightarrow{{e/}_{X1,X2}}\) SX2\(\:\underrightarrow{{e/}_{X2,X3}}\)CX3\(\:\underrightarrow{{e/}_{X3,X4}}\)AX4, then CPSSA\(\:\)Reac, where Xi denotes port, Reac denotes Completeness, \(\:\)denotes that it satisfies some property.

Proposition 4

Evolution rules of information flow can guarantee consistency, completeness and reachability. Formally, suppose CPSSA0 = (V, D, I, E, Prnt, Link), where V=(M, S, C, A), CPSSA0\(\:\)Const, CPSSA0\(\:\)Inte, CPSSA0\(\:\)Reac, if the evolution rule of information flow is \(\:{R}_{\:}^{{\prime\:}}\)={r3, r6, r9}, CPSSA0 \(\:\underrightarrow{{r}_{1}}\) CPSSA1\(\:\underrightarrow{{r}_{2}}\) CPSSA2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\) CPSSAn−1\(\:\underrightarrow{{r}_{n}}\) CPSSAn, ri\(\:\in\:{R}_{\:}^{{\prime\:}}\), \(\:n\in\:{N}^{*}\), then CPSSAn\(\:\)Const, CPSSAn\(\:\)Comp, CPSSAn\(\:\)Reac, CPSSAi is the intermediate state.

Proof 4

(1) When n = 1, the target Bigraph is CPSSA1. It is known that the transformation from CPSSA0 to CPSSA1 involves only the addition, deletion, or replacement of one entity I. For any ri\(\:\in\:{R}_{\:}^{{\prime\:}}\), it satisfies \(\:\forall\:{M}_{X}\), \(\:\exists\:{S}_{Y}\), \(\:\exists\:{\text{e}/}_{X,Y}\), and \(\:\forall\:{S}_{X}\), \(\:\exists\:{C}_{Y}\), \(\:\exists\:{\text{e}/}_{X,Y}\), and \(\:\forall\:{C}_{X}\), \(\:\exists\:{A}_{Y}\), \(\:\exists\:{\text{e}/}_{X,Y}\), and \(\:\forall\:{A}_{X}\), \(\:\exists\:{M}_{Y}\), \(\:\exists\:{\text{e}/}_{X,Y}\), \(\:\forall\:I\), \(\:\exists\:\)S(I), or \(\:\exists\:\)C(I), or \(\:\exists\:\)A(I), i.e., CPSSA\(\:\)Const. It can also satisfy \(\:\forall\:\)D, \(\:\exists\:\){D(S1), D(S2), …, D(Sp)}, p\(\:\ge\:\)m, and \(\:\forall\:\)CX, \(\:\exists\:\){\(\:{S}_{Y1}^{1}\), \(\:{S}_{Y2}^{2}\), …, \(\:{S}_{Yp}^{p}\)}, {\(\:{\text{e}/}_{X,Y1}\), \(\:{\text{e}/}_{X,Y2}\),…., \(\:{\text{e}/}_{X,Yp}\)}, p\(\:\le\:\)n, and \(\:\forall\:\)CX, \(\:\exists\:\){\(\:{A}_{Y1}^{1}\), \(\:{A}_{Y2}^{2}\), …, \(\:{A}_{Yt}^{p}\)}, {\(\:{\text{e}/}_{X,Y1}\), \(\:{\text{e}/}_{X,Y2}\), …., \(\:{\text{e}/}_{X,\text{Y}t}\)}, t\(\:\le\:\)k, i.e., CPSSA\(\:\)Inte. It can also satisfy \(\:\forall\:\)M, \(\:\exists\:\)Path: MX1\(\:\underrightarrow{{e/}_{X1,X2}}\) SX2\(\:\underrightarrow{{e/}_{X2,X3}}\)CX3\(\:\underrightarrow{{e/}_{X3,X4}}\)AX4, i.e., CPSSA\(\:\)Reac. Therefore, for CPSSA0 \(\:\underrightarrow{{r}_{i}}\) CPSSA1, the CPSSA1\(\:\)Const, and CPSSA1\(\:\)Comp, and CPSSA1\(\:\)Reac hold.

(2) Suppose when n = k, CPSSA0 \(\:\underrightarrow{{r}_{1}}\) CPSSA1\(\:\underrightarrow{{r}_{2}}\) CPSSA2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\) CPSSAk−1\(\:\underrightarrow{{r}_{k}}\) CPSSAk, holds. Similarly to CPSSA0 \(\:\underrightarrow{{r}_{i}}\) CPSSA1, the CPSSA1\(\:\)Const, and CPSSA1\(\:\)Comp, and CPSSA1\(\:\)Rea hold. For any Bi−1 \(\:\underrightarrow{{r}_{i}}\) Bi, the CPSSAi\(\:\)Const, and CPSSAi\(\:\)Comp,and CPSSAi\(\:\)Reac hold.When n = k + 1, CPSSA0 \(\:\underrightarrow{{r}_{1}}\) CPSSA1\(\:\underrightarrow{{r}_{2}}\) CPSSA2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\) CPSSAk\(\:\underrightarrow{{r}_{k+1}}\) CPSSAk+1 can be transformed into CPSSA0 \(\:\underrightarrow{{r}_{1}}\) CPSSA1\(\:\underrightarrow{{r}_{2}}\) CPSSA2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\) CPSSA(k+1)−1\(\:\underrightarrow{{r}_{k+1}}\) CPSSAk+1.Therefore, when n = k+1, for CPSSA0 \(\:\underrightarrow{{r}_{1}}\) CPSSA1\(\:\underrightarrow{{r}_{2}}\) CPSSA2\(\:\underrightarrow{\:}\)\(\:\underrightarrow{\:}\) CPSSAk\(\:\underrightarrow{{r}_{k+1}}\) CPSSAk+1, the CPSSAk+1\(\:\)Const, and CPSSAk+1\(\:\)Comp, and CPSSA k+1\(\:\)Reac hold.

From (1) and (2), we can conclude that the proposition holds true for all positive integers n\(\:\in\:{N}^{*}\).

In CPS, consistency checking of the system is required to avoid system insecurity, as the system consistency may be destroyed by the use of evolution rules. The main idea of the consistency checking method is illustrated in Fig. 16. To address various application scenarios, I further categorize it into three types of consistency methods: (1) Perform a global consistency check only once after all the evolution rules are executed, its specific process is shown in Algorithm 1. (2) When every evolution rule is used, a global consistency check is performed. This allows early checking of inconsistencies without global rollbacks. When the number of evolution rules is less, the execution efficiency is very good. However, as the number of evolutionary rules increases, the evolutionary execution time will be too long and the execution efficiency will be low, its specific process is shown in Algorithm 2. (3) When every evolution rule is used, a local consistency check is performed. In other words, the scope of influence of an evolution rule is knew, and then only the scope of influence is checked. When the scale of the architecture is getting larger and larger, the efficiency of this method is quite high, its specific process is shown in Algorithm 3.

Fig. 16
Fig. 16
Full size image

Consistency checking flowchart.

figure a

Algorithm 1. Checking Architecture Consistency, Abbreviated CSC1.

figure b

Algorithm 2. Checking Architecture Consistency, Abbreviated CSC2.

figure c

Algorithm 3. Checking Architecture Consistency, Abbreviated CSC3.

In CPS, since the system integrity may be destroyed by using evolutionary rules, the system needs to be checked for integrity to avoid system insecurity. In terms of integrity checking, when all evolution rules are executed, only one global integrity checking is performed. Because integrity mainly involves the number of entities, it is not necessary to check every evolution rule after it is executed. If that is done, the execution efficiency is too low. Its specific process is shown in Fig. 17 and Algorithm 4.

Fig. 17
Fig. 17
Full size image

Integrity checking flowchart.

figure d

Algorithm 4. Checking Architecture Integrity, Abbreviated CAI

In CPS, since the system reachability may be destroyed by using evolutionary rules, the system needs to be checked for reachability to avoid system insecurity. In terms of reachability checking, when all evolution rules are executed, only one global reachability checking is performed. Because reachability mainly involves the global entities, it is not necessary to check every evolution rule after it is executed. If that is done, the execution efficiency is too low. Its specific process is shown in Fig. 18 and Algorithm 5.

Fig. 18
Fig. 18
Full size image

Reachability checking flowchart.

figure e

Algorithm 5. Checking Architecture Reachability, Abbreviated CAR

Instance and experimental analysis

Experiment 1: Evolution modeling and analysis for smart meeting room system.

Smart meeting room system modeling

A smart meeting room system is an office system that enables companies to enhance the comfort and efficiency of their meetings. It is a representative example of cyber-physical systems. It involves various entities. Initially, Table 4 presents the fundamental control set for the smart meeting room system. Subsequently, the Bigraph modeling tool, BigRed39, is utilized to establish the initial Bigraph model of the smart meeting room system, as illustrated in Fig. 19.

In Fig. 19, the smart meeting room system mainly consists of one environmental place entity smartmeetingroom, two environmental entities air and light, one temperature sensor tempsensor, one light sensor lumsensor, one global controller, and four actuators: aircd, curtain, lamp, and projector. The system assumes that these actuators are all off in the initial state, represented by the closed entity off, which is embedded in each of these actuators. It is also assumed that the temperature sensor and the light sensor perceive hot information and weak light intensity respectively in the initial state, represented by the entities hot and weak. The connection relationships of these entities are shown in Fig. 19. Air is connected to tempsensor, light is connected to lumsensor, tempsensor and lumsensor are both connected to controller, and controller is connected to aircd, curtain, lamp, and projector respectively.

Fig. 19
Fig. 19
Full size image

Initial Bigraph model of the smart meeting room system.

Table 4 Control set of smart meeting room system.

Modeling of evolution rules

The meeting room is often used for long meetings and is closed most of the time, which makes people feel dry and uncomfortable. Therefore, people want to upgrade the smart meeting room facilities to add a humidification function, without affecting the normal operation of the existing system. To achieve this, a humidifier, a humidity sensor, and two indicators of high and low humidity are needed. However, the original controller has a limited capacity and cannot control more than four actuators, so it needs to be replaced with a more powerful controllerplus. To achieve these evolution objectives, as shown in Figs. 20, 21, 22 and 23, and Fig. 24, four add evolution rules, namely r11, r12, r13, and r14, as well as one replace evolution rule r15 are designed.

  1. (1)

    Add evolution rules.

Fig. 20
Fig. 20
Full size image

Add evolution rule for humidity sensor r11.

Fig. 21
Fig. 21
Full size image

Add evolution rule for humidifier r12.

Fig. 22
Fig. 22
Full size image

Add evolution rule for initial state of humidifier r13.

Fig. 23
Fig. 23
Full size image

Add evolution rule for initial state of air humidity r14.

  1. (2)

    Replace evolution rule.

Fig. 24
Fig. 24
Full size image

Replace controller evolution rule r15.

  1. (3)

    Information flow evolution rule.

The smart meeting system has an information flow feature, which means that information can move between different entities in the system. This movement needs to be captured by evolution rules in the model, called information flow evolution rules. Information is an atomic entity that can be embedded in various other entities. For example, when the humidity sensor detects low humidity in the air, the low information will transfer from the air entity to the humidity sensor entity. This can be expressed by the information flow evolution rule shown in Fig. 25.

Fig. 25
Fig. 25
Full size image

Evolution rule for humidity sensor perception and acquisition of humidity information flow r16.

The term language representation of the evolution rules above is as follows:

r11:smartmeetingroom(airx|controlleryz)\(\:\to\:\)e1/x, u.e2/v, y.smartmeetingroom(airx|humisensoruv|controlleryz).

r12:smartmeetingroom(controlleryz)\(\:\to\:\)e3/z, w.smartmeetingroom(controlleryz|humidifierw).

r13: humidifierw\(\:\to\:\)humidifierw(off).

r14: airo\(\:\to\:\)airo(low).

r15 :e4/p, y.e5/z, q.smartmeetingroom(tempsensorp|controlleryz|curtainq)\(\:\to\:\)e6/p, r.e7/s, q.smartmeetingroom(tempsensorp|controllerplusrs|curtainq).

r16: e6/o, u.airo(hot|low)|humisensoruv\(\:\to\:\)e6/o, u.airo(hot)| humi sensoruv(low).

It can be seen that our method not only has an intuitive graphical expression of evolution rules, but also has a strict formalized algebraic semantic expression of evolution rules.

Rule-driven system function evolution

In order to achieve the evolution goal and meet the user’s evolution requirements, a software engineer first used the evolution rule r11 to add the humisensor, then used r12 to add the humidifier, then used r13 to set the humidifier to the initial state off, then used r14 to add the initial humidity state low in the air, and finally used r15 to replace the controller with a more powerful controllerplus. The final evolution result is shown in Fig. 26. As can be seen from Fig. 26, the original functions and function logic of the software system are not affected, only the automatic humidification function is extended, which meets the user’s evolution requirements. This shows that as long as a clear user evolution requirement goal is given, it is always possible to use a finite number of evolution rules to achieve the target requirement, which proves the correctness of Proposition 1 from the actual system. In order to ensure the reliability of the system after evolution, it is also necessary to further check the consistency, integrity and reachability of the system after evolution, which will be discussed later.

Fig. 26
Fig. 26
Full size image

Bigraph model of smart meeting system after evolution.

Rule-driven system information flow evolution

Rule r16 can express that the humidity low in the air is perceived and acquired by the humisensor. The Bigraph model of the system evolution after applying the rule is shown in Fig. 27. This intuitive way of expression is conducive to the visualization and understanding of the model. The Bigraph model also has a rigorous mathematical formal semantics, which can be used for the global representation of system states.

Fig. 27
Fig. 27
Full size image

Bigraph model of smart meeting system after information flow evolution.

Reliability checking of system evolution

  1. (1)

    Consistency checking.

Figure 28 shows the Bigraph model of the smart meeting system after evolution using the evolution rules by the software engineer, which leads to the lack of connection between humisensor and controllerplus due to negligence. The algorithms CSC1, CSC2, and CSC3 are used to check the consistency of the evolved Bigraph model, respectively, and can detect that the lack of connection between humisensor and controllerplus causes the inconsistency of the system. This also illustrates the necessity of consistency checking on the one hand, and verifies the correctness of our algorithm design on the other hand.

Fig. 28
Fig. 28
Full size image

the Bigraph model with lacking the connection after evolution.

In order to verify the detection efficiency of the consistency detection algorithm, five equal-interval inconsistency test points were set up as the number of entities in the smart meeting system model increased, and the average detection time of these test points was calculated and used to measure the detection time at a certain scale. Firstly, the CSC1 algorithm are used for test point detection, and the corresponding average detection time is shown in Table 5. By observing the average detection time, it can be seen that the average detection time generally increases with the increase in scale, but it is not proportional to the number of scales. This also reflects that as the number of entities increases, the relationship between entities becomes more complex and requires more detection time, but overall, it is at the nanosecond level, and the detection time efficiency is very high. These detection times are relatively small compared to the time spent on system evolution, so it is feasible to add consistency detection during system evolution, which can also ensure consistent system evolution. The detection time of the CSC2 algorithm under equivalent conditions is approximately twice that of the CSC1 algorithm. When the influence range of the CSC3 algorithm is 1/k of the overall range, the detection time of the CSC3 algorithm is approximately 1/k of that of the CSC1 algorithm. Since the detection methods are similar, they will not be repeated.

Table 5 The average checking time of the CSC1 consistency algorithm under different entity sizes.
  1. (2)

    Integrity checking.

In the integrity check, the assumption is made that the old controller can connect up to two sensors, and the Bigraph model of the smart meeting system after evolution is shown in Fig. 29. The model is the software engineer using the evolution rules to add humisensor and humidifier, and forgetting to replace the old controller with controllerplus. The detection algorithm CAI is used to perform integrity check on this model, and can detect that controller connects three sensors: lumsensor, tempsensor, and humisensor, which violates the integrity constraint that the old controller can connect up to two sensors. Through such an integrity check, the satisfaction of the system model with relevant constraints and requirements is ensured, thereby further guaranteeing the system’s reliability.

Fig. 29
Fig. 29
Full size image

Bigraph model with integrity errors after evolution.

To evaluate the efficiency of algorithm CAI for integrity checking, we design the smart meeting system to record the time consumption of detecting the controller with integrity constraint errors under different entity numbers. As shown in Table 6, the total detection time does not increase proportionally when the entity number doubles. The main reason is that the controller is in the middle position of the model, and the time to search for the controller entity is similar, and the time difference mainly relies on the subsequent judgment of the number of other entities connected by the controller. The experimental results indicate that the detection time of integrity constraints is at the nanosecond (ns) level, which is very low compared to the other operations of the whole evolution. From the perspective of model reliability, it is worthwhile to perform corresponding integrity check after evolution, and the cost is very small.

Table 6 The total checking time of the CAI integrity algorithm under different entity sizes.
  1. (3)

    Reachability checking.

In the reachability check, assuming that the humidifier is added by using the evolution rule, but it is not connected to controllerplus due to negligence, and the Bigraph model of the smart meeting system after evolution is as shown in Fig. 30. The checking algorithm CAR are applied to perform reachability check on this model from two environment entities air and light, and detect that humidifier is not connected to controllerplus, which violates the reachability constraint. Through such reachability check, it can ensure that the system model meets the constraints of relevant requirements, and thus further enhance the reliability of the system.

Fig. 30
Fig. 30
Full size image

Bigraph model with reachability errors after evolution.

To evaluate the efficiency of algorithm CAR for reachability checking, the smart meeting system to measure the time consumption of detecting the reachability of all entities under different entity numbers are designed. As shown in Table 7, the total detection time increases linearly when the entity number doubles. The main reason is that the reachability check has to traverse all paths, and the increase of entity number leads to almost linear growth of reachable paths. The experimental results show that the detection time of reachability constraints is at the nanosecond (ns) level, which is very low compared to the other operations of the whole evolution. From the perspective of model reliability, it is worthwhile to perform corresponding reachability check after evolution, and the cost is very small.

Table 7 The total checking time of the CAR reachability algorithm under different entity sizes.

The above experimental analyses shows that our proposed modeling method can effectively address the evolution modeling problem of cyber-physical system, and can provide graphical and algebraic representations of the evolution process of cyber-physical system, laying a solid mathematical semantic foundation for the evolution analysis of the system.

Experiment 2: evolution modeling and analysis for internet of vehicles system

Modeling for internet of vehicles system

Internet of vehicles system is a typical application of cyber-physical system, which is an important carrier of the next generation intelligent vehicle system. It consists of various vehicular systems that are organized in a distributed way. Each vehicular system is composed of a series of functional components, and they communicate with each other mainly through wireless communication. The system involves many entities, and the basic control set of the Internet of vehicles system are presented, as shown in Table 8. Based on this, the Bigraph modeling tool BigRed to used to construct the initial Bigraph model of the Internet of vehicles system, as shown in Fig. 31.

Table 8 Control set for internet of vehicles system.

Figure 31 shows an Internet of vehicles system composed of two cars, which is mainly formed by the cyber-physical vehicular systems of each car through a wireless signal network in a distributed way. Each cyber-physical vehicular system mainly consists of environmental place entity road, and environmental entities barrier, people and car. The environmental entity car includes roadsensor, barriersensor, personsensor, carsensor, controller, accelerator, brake, and warning. And the environmental entities car communicate with each other through wireless network entity signaltower. The connection relationships of these entities are shown in Fig. 31. The sensor connects to both the corresponding perceived entities road, barrier, people and car, and the global controller. The controller connects to all the control objects accelerator, brake, warning.

Fig. 31
Fig. 31
Full size image

Initial Bigraph model of Internet of vehicles system.

Evolution rule

The primary goal of vehicular networking is to connect a car to the system, so the first step is to design a networking evolution rule for a car. Secondly, since the vehicular network system currently lacks visualization of various sensor data, people want to equip each car in the system with a visual display, so a functional component entity displayer for visualization is also required. In addition, since the original controller cannot control the functional component displayer, it needs to be replaced by a controller1 that can support this function. Moreover, since the displayer functional component has a warning function already, the warning functional component warning needs to be removed to avoid redundancy. Therefore, the following evolution rules need to be designed, as shown in Fig. 32 for a car networking evolution rule, as shown in Fig. 33 for an add displayer evolution rule, as shown in Fig. 34 for a replace controller evolution rule, and as shown in Fig. 35 for a delete warning evolution rule. Due to the limited space, the term language expression forms of the evolution rules are not given here, and their expression forms are the same as those of experiment 1.

  1. (1)

    A car networking evolution rule.

Fig. 32
Fig. 32
Full size image

A car networking evolution rule r21.

  1. (2)

    Add displayer evolution rule.

Fig. 33
Fig. 33
Full size image

Add displayer evolution rule r22.

  1. (3)

    Replace controller evolution rule.

Fig. 34
Fig. 34
Full size image

Replace controller evolution rule r23.

  1. (4)

    Delete warning evolution rule.

Fig. 35
Fig. 35
Full size image

Delete warning evolution rule r24.

System evolution

In order to achieve the evolution goal of adding a car to the current system, and adding a displayer component, replacing a stronger controller component, and deleting a redundant warning component. A software engineer first uses the evolution rule r21 to add a car to the system, then uses r22 to globally add the displayer component, then uses r23 to globally replace the old controller component with the new component controller1, and finally uses r24 to delete the redundant warning component. The final evolution result is shown in Fig. 36. From Fig. 36, it can be seen that the original functions and function logic of the vehicular network system are not affected, but only one car is added to the network, and the displayer function is added, the stronger controller1 is replaced, and the redundant warning function is deleted, which meets the user’s evolution requirements. This shows that as long as a clear user requirement goal is given, it can always be achieved with a finite number of evolution rules, which proves the correctness of Proposition 1 from the actual system again. After evolution, further verification of the system’s consistency, integrity and reachability is needed, which will be discussed later.

Fig. 36
Fig. 36
Full size image

Bigraph model of Internet of vehicles system after evolution.

Performance of checking algorithm

To verify the checking efficiency of the three algorithms CSC1, CAI, and CAR, the time consumption of checking all entities for consistency, integrity, and reachability after evolution with different entity numbers are measured. Similar to Experiment 1, the detection times corresponding to the three algorithms under the scenario of increasing entity counts in Tables 9 and 10, and 11 are presented, respectively. Based on the experimental results, as the scale of entities continues to increase, the detection times for all three algorithms also show an upward trend. Overall, the detection time for consistency is at the nanosecond level, while the detection times for integrity and reachability are both in the tens of microseconds. Compared to the minute-level durations of other operations in the entire evolution process, these detection times remain relatively low. From the perspective of model reliability, it is absolutely necessary to conduct corresponding checks for consistency, integrity, and reachability after evolution, and the cost involved is minimal.

Table 9 The average checking time of the CSC1 consistency algorithm under different entity sizes.
Table 10 The total checking time of the CAI integrity algorithm under different entity sizes.
Table 11 The total checking time of the CAR reachability algorithm under different entity sizes.

Discussion

Through the analysis of the above two experiments, it can be seen that the Bigraph modeling method can effectively address the modeling issue of both the connectivity and positional relationships of entities in the evolution of cyber-physical systems (CPS). Compared to traditional single-dimensional modeling approaches such as graphs and hypergraphs, it better aligns with the two-dimensional spatial modeling of CPS. Due to the difference in dimensions, it is not feasible to directly compare our method’s performance in terms of consistency, integrity, and reachability with traditional single-dimensional modeling methods like graphs and hypergraphs. However, based on the performance analysis results from Experiment 1 and Experiment 2, when the scale of entities reaches 370, the most time-consuming integrity check only takes 30,589 nanoseconds, which is negligible compared to the minute-level duration of evolution operations. It is evident that our method can be extended to larger-scale CPS.

Conclusion

Oriented towards the need for a rigorous mathematical semantic description of the update and evolution processes of cyber-physical systems (CPS), this paper proposes a modeling method for the evolution of CPS architecture based on Bigraph. Essentially, this research not only presents an effective method for CPS modeling, but also provides a solution to the problem of simultaneously modeling connections and locations. The innovative aspects of this research mainly consist of the following three parts:

  1. (1)

    The Bigraph model for Cyber-Physical Systems (CPS) proposed in this study can not only represent one-to-one relationships between entities within CPS but also accommodate one-to-many and many-to-many relationships, thereby fulfilling the need to express complex relationships among entities in the cyberspace.

  2. (2)

    A set of dynamic evolution rules tailored for CPS architecture has been designed, and a model for the dynamic evolution of CPS structure and information flow has been proposed, drawing on the concepts of conditional matching and state transition.

  3. (3)

    Algorithms for checking consistency, integrity, and reachability constraints in the dynamic evolution of CPS architecture have been designed, thereby ensuring the correctness and reliability of the CPS system after its dynamic evolution.

However, the research in this paper has some limitations.

  1. (1)

    Our current work focuses more on the evolution of system entities and does not address the issue of whether entity evolution is safe. For instance, if a particular entity is a crucial part of the system, evolving it may affect and propagate changes to other entities. The scope of its impact needs to be assessed, and an evaluation of evolution safety is required. Such evolution safety assessment can be further analyzed using our proposed Bigraph model. For example, the link graph of Bigraph can be used for safety assessment analysis of the impact scope of entity relationships, while the place graph can be used for safety scope analysis of the physical location impact of entities.

  2. (2)

    Furthermore, there is a need to delve deeper into the scalability of Bigraph within Cyber-Physical Systems (CPS), such as its extension in modeling the evolution of large-scale unmanned aerial vehicle (UAV) swarm systems. Its ability to extend when modeling the evolution of large-scale cooperative unmanned vehicle systems. The expansion needs of different systems vary, and analysis is needed on whether Bigraph possesses the capability for adaptive expansion.

  3. (3)

    The efficiency of detecting various properties during the evolution of the cyber-physical system Bigraph model also requires further research. Particularly in scenarios with non-stop conditions, if the detection time occupies a significant portion of the entire evolution time, it may affect the continuity of system service provision, making it difficult to meet the requirements of high-quality service-oriented cyber-physical systems.

  4. (4)

    Further research is also needed on the Bigraph model for real-time cyber-physical systems. The Bigraph model proposed in this paper does not address temporal attributes. However, in real-world cyber-physical systems, there are many real-time scenarios where evolution might compromise the system’s real-time performance. It is necessary to extend the Bigraph model to incorporate temporal attributes, enabling the analysis of these attributes and ensuring their satisfiability.

Therefore, our future work will focus more on the above four areas research of CPS evolution.