Towards Leveraging the Concept of Influence to Enhance Collaborative Cyber-Physical Systems Development

Towards Leveraging the Concept of Influence to Enhance Collaborative Cyber-Physical Systems Development Bárbara da Silva Oliveira barbara.da-silva-[email protected] cotedazur.fr Université Côte d’Azur, I3S/INRIA Kairos Sophia Antipolis, France Nicolas Ferry [email protected] Université Côte d’Azur, I3S/INRIA Kairos Sophia Antipolis, France Julien Deantoni [email protected] Université Côte d’Azur, I3S/INRIA Kairos Sophia Antipolis, France Abstract Cyber-Physical Systems development requires the collaboration of various stakeholders from multiple domains. Whilst the functional exchanges between the design artifacts are captured using classical software engineering methods, it is common to have interactions between di�erent domains that go beyond mere functional ones. These may not even be fully understood or known at design-time, making more di�cult the rationalization of the design choices and generally speaking the collaboration. Collaborative simulation appears as a solution to observe the emerging behaviors of such systems. However, it does not help identifying the cause of changes in the emerging behaviors, e.g., when di�erent teams made changes concurrently on their artifacts. In this paper, we propose to make explicit how some elements of the design artifacts are known (more or less precisely) to in�uence the behavior of other design artifacts. We argue this is bene�cial for the collaborative development of CPS since it provides an enrichment of the (potentially not fully understood) semantics that exist between di�erent elements of the systems, beyond mere functional ones. Based on our example, the paper presents a �rst categorization for our notion of in�uences as well as a discussion about potential usages and their bene�ts. Keywords Cyber-Physical Systems, Collaborative System Design, Collaborative Simulation, System Behavior 1 Introduction Cyber-Physical Systems (CPS) have emerged as a transformative technology, integrating physical and computational processes. CPS are composed of interconnected parts, each designed to ful�ll speci�c roles within the system [ 3 , 13 ]. These parts are typically de�ned based on domains of expertise, such as hardware, software, network, and can be further divided into more specialized parts. They are often developed independently in silos by di�erent developers, teams, and organizations. Before delivery, the material created during this process (e.g., code, models, con�gurations), hereafter called design artifact [ 6 ], needs to be evaluated realizing simulations, experimentation, and tests. However, analysing the behavior of individual parts running isolated simulations is not su�cient as interaction across design artifacts from the di�erent parts needs to be considered. Collaborative simulation has emerged as an essential technique for evaluating the interactions between multiple system parts. Simulation results related to a part of the system are considered in relation to others, providing simulation outcomes that re�ect the emerging behavior of the system [ 5 ]. However, despite paving the way of understanding the complete system behavior, some limitations still remain. Co-simulation typically produces large volume of raw logs, from which it is di�cult to assess the impact of a novel design choice on the whole system. Design choices made in one design artifact may have far-reaching consequences, especially when dealing with large and heterogeneous design spaces as in CPS [ 12 ]. Design choices in one part of the system may in�uence other parts’ behavior, possibly violating their requirements or worsening their outcomes. Without clear visibility on how di�erent artifacts in�uence each other, beyond mere functional exchanges captured using classical software engineering methods, it becomes di�cult to identify (statically or dynamically using co-simulation) the consequences of changes and to ensure that the system behaves as intended. As a result, it becomes challenging to make accurate decisions and progress through the development lifecycle. In this paper we argue that, beyond the abstractions, and speci- �cations identi�ed by a development team to reach the system’s desired goals, making explicit how design choices on design artifacts, or elements of design artifact, in�uence the behavior of other design artifacts is bene�cial for the collaborative development of CPS. The objective of this paper is to propose a de�nition of the concept of in�uence together with a conceptual work�ow to exploit this novel knowledge during CPS development. Our contribution is focused on the de�nition and classi�cation of in�uences, which we illustrate and motivate this concept using a mobile robot use case. We describe a conceptual work�ow for the development of CPS, incorporating the concept and the exploration of in�uences into the system development. By improving the comprehension of these in�uences, we intend to enhance decision-making and collaboration between the various users involved in a system development. The remainder of the paper is organized as follows. Section 2 presents our motivating example. Section 3 introduces the concept of in�uences. Section 4 outlines the conceptual framework we aim to implement. Section 5 positions our contribution within the state of the art and Section 6 concludes. 2 Mobile Robot Use Case In this section, we introduce our exploration robot as a use case from which we extracted design scenarios that motivate the need for extra information to ease collaborative development. The robot used is a Cherokey 4WD Arduino mobile robot [ 4 ]. This simple robot, equipped with useful but limited hardware, is Bárbara da Silva Oliveira , Nicolas Ferry , and Julien Deantoni often used for student competitions/teaching and research activities. The requirements for the robot are simple: the robot must explore an indoor environment while avoiding obstacles. The robot moves by using two gearboxed DC motors. It uses a RoMeo V1 Board, which is based on Arduino Uno and includes an ATmega328 microcontroller. The robot is equipped with a servo rotary motor that allows an ultrasonic sensor to sweep the environment and detect obstacles. The ultrasonic sensor measures the proximity of objects with the transmission of ultrasonic pulses. It is worth mentioning that our contribution is not focused on the domain of robotics but on the exploration of the system development process for motivating our work. In the following, we detail the di�erent parts of the system, their model, and key design artifacts. 2.1 System Design Model Description The system is divided into the following six parts (see Figure 1): Wheel Controller This part receives move commands and applies the power to the right and left wheels accordingly. Examples of move commands are forward , stop , or turnLeft . Dynamic Detection : Checks for dangerous obstacles while sweeping the environment in front of the robot. This part is active while the robot is moving. Static Detection : scans for obstacles in front and on the sides of the robot; for a better understanding of the environment and accurate avoidance decisions. Avoidance Strategy : From an ordered set of detected obstacles, decides the maneuvers necessary to avoid detected obstacles. These maneuvers are provided as timed moves, i.e., a set of move command and their duration. Normal Move : Sends move commands to explore the environment. Avoidance Move : Receives a set of timed moves and applies them iteratively for the speci�ed duration. These di�erent parts are not all enabled at the same time and are orchestrated as speci�ed by the State Chart represented in Figure 2. The name of the states corresponds to the name of the parts introduced in Figure 1. When a state is entered, the behavior of the part is started. When a state is exited, the behavior is aborted. At the start of the system, both the normal move and the dynamic detection (of obstacles) are performed. If an obstacle is detected, both stop, and the static detection (of obstacles) is started. When �nished, the avoidance strategy is executed. Either the avoidance strategy decides to continue as is and reenter the parallel state with the normal move and dynamic detection; or some maneuvers to avoid the obstacles are computed; followed by the parallel execution of the avoidance move and the dynamic detection. Finally, the behavior of some of the individual system parts is detailed in Figure 3 using activity diagrams. These activity diagrams are given for record and we detail only speci�c parts of each behavior here. In the Dynamic Detection, the servo motor position is changed (to sweep the environment); followed by an obstacle check by using the ultrasonic sensor. The designer of this part’s behavior decided to consider that a dangerous obstacle is one whose distance is less than 15 cm from the robot (see decision node’s predicate). If it occurs, an event is emitted, �ring a transition in the orchestrator state chart. If not, sleep is realized before restarting the obstacle checking. During Static Detection, the stop move command is sent in order to realize a precise object scanning. The sweep of the environment is done almost like in the dynamic detection part except that the sweep is wider, all detected obstacles are put in a FIFO, and that no sleeps are realized. Once the whole sweep of the environment is done, the behavior is stopped, and the avoidance strategy is started. In the avoidance strategy, if the danger is con�rmed, a set of timed move commands are generated and sent to the avoidance move, which is started in turn (in parallel with the dynamic detectionAvoidance commands are then sent as appropriate. Once all maneuvers are completed with no new obstacle detection, the normal move is restarted. 2.2 Motivating scenario This use case is small but su�cient to illustrate some di�culties that may appear during the collaborative development of a CPS. We illustrate these di�culties through the de�nition of scenarios. Alice, Bob, and Charlie are software developers working on the autonomous robot. Alice works on the Static and Dynamic Detection parts, Bob works on the Avoidance Strategy part, and Charlie works on the Wheel Controller part. They collaborate through the usage of a common artifact repository and cosimulation of the developed artifacts, the physical environment, and the model of the robot. At some point in the development, Charlie was required to speed up the exploration to better handle large buildings. He decided to increase the power on each wheel of the robot with the objective of increasing its speed when managing the forward command. The whole system was then co-simulated, including Charlie’s modi�cations. Charlie observed a bene�cial speed-up in the exploration. However, he also observed an increasing number of collisions. Charlie, not being an expert on this topic, he created an issue about the collision problem. Both Alice and Bob checked if the problem was on their side. Alice observed in her logs that the obstacles were successfully detected and noti�ed. Bob observed in his logs that the avoidance strategy was de�ned and executed properly as originally planned, but that sometimes the car collided as if the robot did not see the obstacle on time. Alice con�rmed that it was not due to an obstacle detection problem. Alice contacted Charlie and asked him to check that the stop command she sent was correctly realized. Charlie answered that yes, the power on each wheel was set to 0 less than 10ms after the command was sent. All together, they started investigating the global logs to understand the problem. Since the logs were extensive, it took time, but after a deep investigation, they understood that despite the robot being asked to stop on time, the inertia of the robot was delaying the actual stop, causing it to sometimes collide. As a �x, Alice simply increased the distance threshold used to detect an obstacle (in the Dynamic Detection part). After this �x, the robot speeds up the exploration with no collisions. This problem appeared because there is a relationship between the speed of the robot and the time required to immobilize the robot, due to inertia. This factor should be taken into consideration Towards Leveraging the Concept of Influence to Enhance Collaborative Cyber-Physical Systems Development Figure 1: High level model of the system using Block Diagram Figure 2: High level coordination of system parts using State Charts when choosing the distance threshold for the dynamic detection of obstacles. Later in the development process, drawing on their experiences, each time Alice wanted to change this threshold, she noti�ed Charlie so that he could adapt the wheel power; and vice versa. Since Alice is also in charge of developing the static detection, which is triggered when the robot is immobilized, she added a delay between the stop command sending and the start of the environment sweep. Of course, the length of this delay is also in�uenced by the speed of the robot. This scenario illustrates that, despite many relationships being made explicit in the various artifacts, some (cyber-physical) relationships are missing and stay only in the heads of the stakeholders. Keeping hidden some of these relationships may lead to communication problems and a longer time to delivery. This motivates the requirement for a tool-supported solution for making explicit these relationships during the collaborative CPS development. Existing models and design artifacts shall be enriched with the extra information describing how design choices on design artifacts in�uence the behavior of other design artifacts, including from other parts. In the following sections, we introduce our novel concept of In�uence to address this requirement and we discuss how it can be exploited as part of a CPS collaborative development process. 3 On the Concept of In�uences Before digging into our de�nition of in�uence, we �rst extract from our motivating example a set of requirements that must be addressed: Enriching existing models ('1) : Beyond functional exchanges, it shall be possible to enrich existing models and design artifacts with the extra information of in�uence making explicit how design choices on design artifacts in�uence the behavior of other design artifacts. Motivation: CPS development teams typically use classical software engineering methods, languages and models to specify the behavior of the di�erent parts of a system. Agreements and decisions are made to de�ne the right abstraction and granularity level for their models with respect to their objectives. As a result of this abstraction, these models may overlook some interplay between design choices when various stakeholders are collaborating through (possibly di�erent and heterogeneous) artifacts. Whilst the functional exchanges between the design artifacts are captured using classical software engineering methods, it is common to have interactions between di�erent domains that go beyond mere functional ones. Considering our example, there is no information about the possible in�uence of changing the power on wheels onto the rest of the system. Cross design parts and domains ('2) It shall be possible to de�ne in�uences that span across multiple system parts from di�erent domains of expertise and possibly from different stakeholders. Motivation: CPS are composed of interconnected parts with speci�c objectives, which are typically designed by di�erent domain experts. To enhance collaboration, it is important to facilitate the understanding of the in�uence of one designer’s choice on their collaborators’ parts. In our example, Alice focuses on the domain of detection and does not have details on the movement control and obstacle strategy Bárbara da Silva Oliveira , Nicolas Ferry , and Julien Deantoni distance < 15cm Wheel Controler Dynamic Detection servoPositionReset 100ms servoPos  180° servoPos triggerMeasurement echoTimestamp triggerMeasurement echoTimestamp FIFO Danger? new command cmd   moveCommand timedMoves {moveCommand, duration} empty moveCommand, duration duration stopCommand ComputeNextServoPosition StartMeasurement Computedistance Computedistance StartMeasurement ComputeNextServoPosition servoPositionReset stopRobot servoPos Static Detection obstacle staticDetectionDone False True False True obstacleDetected distance startAvoidance FIFO timedMoves computeAvoidanceMoves False True FIFO obstacles FIFO FIFO extractClosestObstacle cancelAvoidance obstacles decomposeMoves sendCommand avoidanceFinished get next handleForward handleStop cmd moveCommand stop forward leftWheelPower rightWheelPower Avoidance Strategy Avoidance Move Figure 3: High level model of the system using Activity Diagrams parts. It would be counterproductive for her to include all the details of other domains in her system speci�cation since it is not part of her expertise and would overcomplicate the system development. As a result, she is unaware of the impact of the changes introduced by Charlie on her part and she has to investigate this manually, e.g., exploring co-simulation logs. Specifying in�uences between some elements of her part to elements of Charlie’s parts could help Alice in her investigation. Cyber-Physical interactions ('3) : In�uences shall be able to represent Cyber-Physical interactions between design artifacts. Motivation: CPS are operating in the physical realm and interactions between the system and its environment can have a critical impact on its proper functioning. An in�uence may relate not only to software interaction but also to the interaction between software elements and the physical world. Considering our motivating example, there is a relationship between the power on wheels parameter and the time required to immobilize the robot due to (i) inertia and (ii) the topology of the ground. Abstraction ('4) : It shall be possible to de�ne in�uences at di�erent levels of abstractions and granularity, yet they should contain enough information to enable static and dynamic analysis of the CPS. Motivation: Depending on the constraints and criticality of an in�uence with respect to the system requirements, one might want to characterize an in�uence more or less precisely. In some cases, high-level de�nitions are su�- cient to provide simple feedback to the developer about the impact of his choice. By contrast, in some situations when the in�uence is critical for the proper functioning Towards Leveraging the Concept of Influence to Enhance Collaborative Cyber-Physical Systems Development of the system, it is necessary to precisely de�ne it. Over time, the de�nition of an in�uence might evolve, e.g., it is re�ned based on experience and trials. This can be due to several factors : (i) evolving requirements call for a more precise de�nition, (ii) experience, trials, and co-simulation needs to be performed to iteratively re�ne the de�nition of an in�uence (because experts were not able to precisely de�ne the interaction at �rst or because it is discovered after execution or simulation of the system). In the context of our motivating example, the impact of inertia can be re�ned after several co-simulation runs, while the ground topology might remain at a high level of abstraction as it is unpredictable. Considering the requirements aforementioned, we de�ne an in�uence as: "the characterization and abstraction of a non fully speci�ed cyber-physical interaction between design choices, which goes beyond the abstractions, models, and speci�cations identi�ed to address the system requirements." It is important to note the distinction with the concept of functional exchange. Functional exchange is a relationship based on functionalities and data exchanges that is intentional and welldocumented. In contrast, in�uences are impacts that one design choice or component can have on another. They are not necessarily (i) identi�ed during design time or (ii) part of the domain. Functional exchanges can lead to the emergence of in�uences, but in�uences do not rely on those interactions. Additionally, in�uences capture behaviors that emerge from the collaboration, which may not be straightforward when designing functional exchanges. In our exploration of the concept of in�uence, we have de�ned characteristics, categories, and metadata of in�uences. These aim to be identi�ed by or provided to the users. During CPS design, users can partially de�ne an in�uence between two artifacts, without being certain about its impacts. For example, they may suspect that their system part is related to another one, but be uncertain about what the impact is or how to represent this impact. They can state that uncertainty about the in�uence, and represent what they know about that. Through collaborative simulation, it is possible to validate or contradict this in�uence and further explore its semantics. Moreover, it is possible to identify in�uences after observing the emerging behavior during simulation. To provide a clear understanding of in�uences, Figure 4 represents examples of identi�ed in�uences during the development of the mobile robot use case. Those examples will be referenced throughout the following subsections. 3.1 Characteristics of In�uences 3.1.1 Endpoints. An in�uence has two endpoints: a source and a target; a change in the source will in�uence the target. Considering requirements '2 and '3 , possible endpoints include design artifacts, parts of the system, and elements of the physical environment (i.e., natural factors and other systems not in control of any users of the CPS under development). The notion of endpoint provides a means to (i) clearly pinpoint the elements involved in the in�uence and (ii) support the notion of directionality of in�uence (cf. 3.1.2). In Table 1, we exemplify sources and targets within our use case. For example, we observed in�uences between the parameters DistanceThreshold (source) and MotorSpeed (target), as well as between the hardware artifact UltrasonicSensor (source) and the part Avoidance Strategy (target). The ambient noise (source) in�uences the quality of the ultrasonic sensor measurement (target), and the ambient wind (source) in�uences the movement part (target) of the robot. In our case study, we did not propose in�uences targeting the environment in which the robot navigates. Nevertheless, such in- �uence could exist, for instance, a requirement can be related to the sound level in the room, and di�erent con�gurations of the speed parameters can lead to the violation of such requirements. Table 1: Source and target de�nitions Source/Target Artifact System part Artifact DistanceThreshold and MotorSpeed UltrasonicSensor and Avoidance Strategy System part Dynamic Detection and UltrasonicSensor Avoidance Strategy and Wheel Controller Environment Noise and UltrasonicSensor Wind and Wheel Controller 3.1.2 Directionality. We observed that in�uences typically have a directionality from a source to a target, i.e., one element in�uences another. We consider bidirectional in�uences when two elements interact with each other, each in�uencing the behavior of the other. In such cases, each endpoint is considered as both a source and a target. An example of bidirectional in�uence is the in�uence between Motor Speed and Detection threshold, as illustrated in Figure 4. If the speed of the robot is changed, the detection threshold must be modi�ed. The same for the other way around, if the detection threshold is modi�ed, the Motor Speed needs to be adjusted accordingly. Classifying the directionality is important to determine how to perform integration and collaboration within the CPS development. An unidirectional in�uence indicates a clear �ow of impact, allowing for a straightforward system integration. A bidirectional in�uence requires a more careful consideration, especially when the in�uence exists between two di�erent system parts. Characterizing these in�uences helps to understand how design changes propagate in the system, and, consequently, improve system troubleshooting. 3.1.3 Influence Semantic. It is crucial to explicitly de�ne the semantics of each in�uence as this will be key to statically or dynamically analyze the behavior of the system and the impact of a design choice. It provides a deeper comprehension of an in�uence, more than its identi�cation, but detailing how the source impacts the target. Following requirement '4 , this can be expressed in a continuum from the highest to the lowest level of abstraction, for instance using rules, conditions, constraints, etc. In�uences can, for instance, be expressed using algebraic expressions and de�ned boundaries of parameters and components. The in�uence between the Motor Speed and the Detection Threshold Bárbara da Silva Oliveira , Nicolas Ferry , and Julien Deantoni inertia Artifact: Detection Threshold Artifact: delayStart Artifact: Motor Speed carForward Artifact: command stopCar Artifact: ComputeDistance System Part: Avoidance Strategy wind System Part: Wheel Controller noise Endpoints Unidirectional Indirect Environment Bidirectional Direct inertia Exogenous External Figure 4: Identi�ed In�uences in the autonomous mobile robot use case can be quantitatively expressed with a function, such as ⇡=5(() , where ⇡ is the detection threshold distance, and ( expresses the motor speed. This mathematical representation helps in characterizing how changes in the motor speed in�uence the detection threshold, providing a clear understanding of their impact and establishing allowed ranges for adjustments. 3.2 Categories of In�uences 3.2.1 Direct and indirect influences. A direct in�uence depicts the relation between a source and a target without any intermediary. One element directly impacts another, without involving other elements; therefore changes in one in�uence the behavior of the other. An in�uence is considered indirect when the interaction between the source and the target involves a physical phenomenon related to the environment in which the CPS is operating. As shown in 4, an example of such in�uence is the relation between the Motor Speed and the Detection Threshold for which inertia needs to be considered. It is important to distinguish between these two type of in�uences. An indirect in�uence implies that part of the interaction between the source and target (i.e., the environment) (i) is not fully under the control of the development team, (ii) can vary depending on the context of the system (e.g., di�erent locations will lead to di�erents interactions), (iii) is unpredictable, all possible changes cannot be anticipated at design-time. 3.2.2 Endogenous, exogenous and external influences. Endogenous in�uences emerge between design artifacts of the same system part. The users who work on that part are experts and in control of the parameters, algorithms, and overall design choices. Exogenous in�uences emerge when they are between design artifacts from di�erent parts. The users do not work on the same system part, and could even work in di�erent organizations. They are not necessarily experts in the domain of both the source and target parts. External in�uences happen when the source or the target of an in�uence is not part of the CPS under development. It can involve environment factors, or other systems not in control of the users. Sometimes, those factors are not included during modeling due to their complexity. So, it may exist an in�uence between two artifacts, caused by an external element that can vary according to context and is not expressed by a functional exchange within the system. As illustrated in Figure 4, the in�uence between the design artifacts Detection Threshold from the Dynamic Detection system part and Motor Speed from the Wheel Controller part is exogenous. The in�uence between the environmental factor Noise and the Compute Distance, in which the ambient noise in�uences the proper functioning of the Ultrasonic Sensor is external. This categorization of in�uence is particularly relevant to identify the stakeholder whose work might be impacted by an in�uence and to adapt the feedback accordingly. In case the in�uence is endogenous, it will be de�ned by an expert in the domain (both source and target are from the same domain) and the in�uence can be used to provide detailed and domain-speci�c feedback on design choices. Exogenous in�uences are bene�cial for promoting a better integration between di�erent system parts. In the case of exogenous in�uences, and by contrast with endogenous in�uences, di�erent domain experts are impacted and feedbacks need to be tailored for their common understanding. External in�uences imply that the physical environment surrounding the CPS is involved and thereby all the uncertainties pertaining to CPS must be considered. Towards Leveraging the Concept of Influence to Enhance Collaborative Cyber-Physical Systems Development 3.3 Metadata of In�uences As detailed in requirement '4 , an in�uence can be more or less precisely de�ned, thereby representing the underlying Cyber-Physical interaction with di�erent degrees of �delity. To leverage in�uences in an informed way when analyzing the system and to understand the impact of certain design choices, it is important to provide indications on the �delity of the in�uences de�nitions. To do so, we introduce two metadata that can be attached to an in�uence in order to characterize the degree of �delity of an in�uence. Further metadata could be added in the future. 3.3.1 Confidence. Con�dence is an indicator of the degree of �- delity of an in�uence semantic de�nition. It can be determined by the users, according to their expertise in the system under development. For example, users with experience contributing to CPS development can provide an initial judgment of their con�dence levels for the identi�ed in�uences. This con�dence level can be further validated or re�ned via co-simulation. Through co-simulation, the emergent system behavior can con�rm the initial con�dence levels determined by the users, or contradict them, providing a validated understanding of the system’s in�uences. 3.3.2 Likelihood. We de�ne likelihood as the probability that the source of an in�uence will impact the target. This is particularly relevant in the case of in�uences with low con�dence level. It can be determined by di�erent methods, indicating how often the in�uence was observed to happen in collected data or while co-simulating. It can be identi�ed that an in�uence is frequent, and expected to always emerge in the system behavior, even with di�erent design choice con�gurations. For example, the in�uences between car speeds and time designed for movements were always observed that in all the recorded occurrences. Otherwise, if the in�uence is barely observed, or only observed in speci�c operational contexts, it can be classi�ed as unlikely. This information are important for decision making, the con�- dence and likelihood metadata can be used to drive CPS behavior analysis as in�uences with higher con�dence and likelihood are more expected to be root causes of issues than others with lower quality levels. 3.4 Discussion In this section, we depicted the concept of in�uences, its categories, characteristics, and metadata. These de�nitions are essential for the improvement of decision-making during system development. Some in�uences can be more easily detected, and the users may be aware of them, due to experience and observations during simulation or experimentation. However, in a context where many �elds of expertise are involved, it can be challenging to have them in mind when developing. A system may have thousands of design artifacts, spread in di�erent domains of expertise and users. Therefore, explicitly identifying the in�uences can facilitate managing this complexity. In addition, since the concept of in�uences goes beyond functional exchanges, it may be unclear for the users how elements can in�uence each other. For example, if two artifacts are separated by di�erent system parts, and many functional exchanges are happening in the system, some in�uences will be not noticed, and their impacts will not be considered as important as they should be. With this enriched understanding of in�uences, we can anticipate potential issues, allowing for preemptive adjustments early in design time. For example, when Charlie tries to commit the change of the speed variable, he receives a noti�cation, stating that his change is not recommended because it may impact other parts of the system. Moreover, the enriched semantics can help deepen the system understanding after co-simulation. The resulting outcomes can be analyzed based on the identi�ed and characterized in�uences. By integrating into automated analysis tools, it could provide not only insights into the identi�cation of root causes, but also an understanding of how this root element caused the issue. For instance, it could provide Bob with the in�uence path from the source of the problem, detailing the characteristics of each in�uence, and indicating possible solutions to mitigate the problem. 4 Conceptual Work�ow for Collaborative CPS Development The de�nition of in�uences can be explored in di�erent stages of the system development process. In Figure 5, we represent the envisaged work�ow. We omitted other phases that are typically part of the development process, such as Requirements Engineering, Planning, etc., to focus on the core aspects of our contribution. The proposed work�ow addresses two main purposes. Primarily, we introduce a static analysis to provide early feedback on the system behavior during the design phase. It is termed static because it has the purpose of examining in�uences in the stage of design without running an execution (simulation or proper execution) of the CPS but solely by analyzing statically the models. By analyzing in�uences in this early stage, it is possible to detect potential issues before their propagation in the development process. Secondly, we incorporate a dynamic analysis to provide feedback based on the resulting system behavior observed during simulations, experimentation, or real-life operations. With the second analysis, we aim to enhance the understanding of the in�uences and discover new ones within the system. 4.1 Leveraging in�uence in the Collaborative CPS design As shown in Figure 5, in the stage of Artifact design, the developers de�ne the initial system models, according to their individual development process. Following that, Semantic Enrichment is realized. During this phase, the same users or experts (e.g. system integration engineer) can identify and de�ne in�uences by exploiting their expertise and experience. They can characterize and add metadata to the in�uence according to their understanding of the system behavior. For instance, they might be con�dent in the existence of an in�uence in the system, based on the development of the same or similar CPS, or they may suspect its existence. Similarly, they may be aware of the existence of an in�uence, but do not know its precise de�nition. In such case they will de�ne new in�uences whose semantics are abstract with a low level of con�dence. This Bárbara da Silva Oliveira , Nicolas Ferry , and Julien Deantoni Part A Influences check Collaborative Simulation Impact Analysis User Tailored Feedback Artifact Design Simulation Semantic Enrichment Iterate Iterate Static Analysis Dynamic Analysis User Tailored Feedback Part B System Developer A System Developer B Figure 5: Integration of our envisaged work�ow on System Development Pipeline process of documenting the current knowledge ensures that a maximum of potential in�uences are considered, even if the details are still not clear. Additionally, it is essential to integrate the models with a versioning control system, to track and maintain a documented history of design changes and in�uences. This ensures that the evolution of in�uences corresponding to the design changes is recorded. The users can revisit and understand why certain changes were made during development, and evaluate the occurrence of origin of new in�uences due to modi�cations. The system will pass through a Static Analysis stage. This stage aims at evaluating the impact of in�uences and checking whether this leads to the violation of some of the system’s requirements and providing feedback to the users accordingly. Metadata, characteristics, and categories attached to the in�uences are exploited to re�ne the analysis results. It may happen that the con�guration of an artifact impacts related artifacts, requiring adjustments of those artifacts to ensure requirements are ful�lled, being in the level of parametrization. Additionally, a design choice may not only impact related elements but also provoke the origin of other in�uences within the system that were not initially considered in the previous phase, with impacts being more on a structural level. These issues may require more signi�cant adjustments and further investigation, which could lead to the need of Dynamic Analysis. This stage includes techniques that compare the initial and new versions of the models, identify the modi�cations, and check if the design changes made could provoke any con�ict. For example, if a developer attempts to modify a design artifact, the impact of this change on the system will be analyzed, based on the in�uences de�ned previously in the Semantic Enrichment stage. The concerned developers are noti�ed and informed about the outputs of the analysis. This may involve developers from di�erent domains, so the feedback must be personalized, providing them with details according to their �eld and role in the CPS development. According to the feedback, they can evaluate the potential issues and collaborate within the involved developers of the CPS to discuss and �nd solutions for identi�ed con�icts. 4.2 Leveraging collaborative simulation for deepening system behavior understanding The second part of the proposed work�ow involves the exploration of collaborative simulation outcomes. It is crucial to observe the system behavior during runtime, as it provides insights into the actual behavior of the system and its evaluation. During the Simulation stage, the multiple system parts are co-simulated, ensuring that data are exchanged and the events are managed between individual simulators. Once the collaborative simulation is performed, the Dynamic Analysis stage starts. The simulation outputs and the known in�uences will be analyzed for the comprehension of the system behavior. The objective is twofold : (i) to re�ne the knowledge about existing in�uences and possibly discover new ones, and (ii) to identify new possible violations of requirements which could not be identi�ed by static analysis only. This involves techniques that can reason on simulation logs. A possible method is to change parameter values and vary other design artifacts, perform co-simulation for each of them, and empirically derive in�uences and their semantics. In case a user identi�ed in�uences between two design artifacts with highlevel semantic de�nition, this method can suggest re�ning it, for instance providing mathematical representations and constraints. Another interesting investigation would be to improve the identi�- cation of the endpoints of an in�uence. For example, if the users identi�ed in�uences between two system parts, but do not know which speci�c design artifact is responsible for the impact and how it happens, the Dynamic Analysis could provide more information on those details. Multiple co-simulation runs can also provide a quantitative evaluation of the system. This evaluation can provide metrics for understanding the observed impact of the in�uences on system behavior. Metadata such as the in�uence’s con�dence and likelihood levels can be derived. Another potential investigation is the analysis of issues in cosimulation results. Through Dynamic Analysis, developers can be provided with feedback on the possible root causes. The unsatisfactory outcomes can be evaluated in the context of the identi�ed in�uences, and developers can be provided with insights into which speci�c artifacts are responsible, for facilitating troubleshooting. Moreover, it can improve collaboration, providing personalized Towards Leveraging the Concept of Influence to Enhance Collaborative Cyber-Physical Systems Development feedback to the identi�ed developers concerned in resolving the issue, according to their roles in CPS development. With Dynamic Analysis, users will be able to make informed iterations in the system model and improve the de�nition and characterization of the in�uences, overall enhancing the system design and integration. In the following iterations, the in�uence checks will be more accurate, the users can identify errors even before the simulation phase. This can reduce system development time, and optimize the use of resources for simulating and prototyping. 5 Related work In recent years, several surveys have been conducted to investigate the semantic relationships existing between artifacts in CPS development. Traceability plays a central role in this investigation, in which is possible to de�ne traces (source and target), enabling the tracking and management of artifacts. In a collaborative system, traceability is a remarkable challenge, since many stakeholders are involved and are part of di�erent organizations [ 14 ]. Capra [ 8 ] and Cameo Systems Modeler [ 2 ] are some examples of tools that o�er traceability management that links requirements to system components, test cases, and other models. However, it is usually a traceability of the static structure of the system, and the dynamics of the system are not explored and explicitly expressed. In [ 9 ], related to software systems, links between behavioral safety requirements to SysML diagrams, presented an algorithm for providing users narrowed view of links related to a given requirement. In [ 1 ], focused on Cyber-Physical Systems, provides links between system goals, requirements, and SysML diagrams, and provides consistency tests to exploit the direct and indirect relationships between artifacts. This work aims to take a step further by exploring deeper details on in�uences within the system, providing deeper details on both static and dynamic analysis of in�uences. Another area in the state of the art is related to tools providing Impact Analysis feedback for the users after collaborative simulation. The INtegrated TOolchain for Cyber-Physical Systems [ 7 ] is a notable framework. In addition to realizing traceability, it utilizes Design Space Exploration (DSE) for �nding alternative designs by ranging parameters and performing co-simulation of each con�guration. [ 11 ] proposed an architecture for supporting tactical and operational decisions exploring Design of Experiments (DOE). This approach provides optimal solutions for each scenario, combining them into a design matrix, so the users can make informed decisions based on expected outcomes. While these works aim to �nd the optimal parameters with co-simulation, our objective contribution is to provide feedback to improve the understanding of the system behavior, improving the semantics of the existing in�uences and discovering new ones. PROSTEP IVIPSoftware [ 10 ] is a relevant work that includes traceability and simulation analysis capabilities. Their approach includes documentation about artifacts through the development cycle, which is used for traceability. Following that, they evaluate the risks from the artifact choices based on simulation results, classifying the critical level of those decisions. In our work, we intend to use simulation results di�erently, evaluating in�uences and identifying new ones, and providing feedback about likelihood, and con�dence level. In light of the discussed state of the art, this work aims to address the limitations of system behavior understanding. Traceability and impact analysis were extensively explored in recent years, however, gaps remain in understanding the in�uences within the system. By leveraging simulation results, our proposed approach seeks to provide a deeper knowledge of system in�uences, which leads to more informed decision-making in complex, collaborative system development environments. 6 Conclusion This paper has introduced the concept of in�uences as a means to enhance collaborative development. Speci�cally, we de�ned the concept of in�uences as the characterization of non fully speci�ed cyber-physical interaction between design choices, going beyond the abstractions identi�ed to address the system requirements. We proposed classi�cations, categories, and metadata of in�uences. By exploring this concept, we aim at enriching system design models for improving decision-making processes. We also propose a conceptual work�ow, that leverages the concept of in�uence to include Static Analysis, investigation at design time, and Dynamic Analysis, investigation after execution of co-simulation, as part of a CPS development process. Our work is in the conceptual stage, and future work will focus on implementing the proposed work- �ow, considering more complex use cases, and further re�ning our approach to ensure e�cient Collaborative Cyber-Physical System development. 7 ACKNOWLEDGEMENTS The research leading to this publication has partially received funding from the European Union’s Horizon Europe research and innovation programme under Grant Agreements 101070455 (DYNABIC). References [1] Amal Ahmed Anda, Daniel Amyot, and John Mylopoulos. 2023. Traceability Management of Socio-Cyber-Physical Systems Involving Goal and SysML Models. Modelling 4, 2 (2023), 133–167. [2] Dassault Systèmes. 2023. Cameo Systems Modeler. https://www.3ds.com/ products/catia/no-magic/cameo-systems-modeler. Accessed: 21/06/2024. [3] Patricia Derler, Edward A. Lee, and Alberto Sangiovanni Vincentelli. 2012. Modeling Cyber–Physical Systems. Proc. IEEE 100, 1 (2012), 13–28. https: //doi.org/10.1109/JPROC.2011.2160929 [4] DFRobot. n.d.. Cherokey 4WD Mobile Platform. https://wiki.dfrobot.com/ Cherokey_4WD_Mobile_Platform__SKU_ROB0102_. Accessed: 01/07/2024. [5] Cláudio Gomes, Casper Thule, David Broman, Peter Gorm Larsen, and Hans Vangheluwe. 2018. Co-Simulation: A Survey. Comput. Surveys 51, 3 (May 2018), 49:1–49:33. https://doi.org/10.1145/3179993 [6] Edward Gri�or, Christopher Greer, David Wollman, and Martin Burns. 2017. Framework for Cyber-Physical Systems: Volume 1, Overview. https://doi.org/ 10.6028/NIST.SP.1500-201 [7] Peter Gorm Larsen, John Fitzgerald, Jim Woodcock, Peter Fritzson, Jörg Brauer, Christian Kleijn, Thierry Lecomte, Markus Pfeil, Ole Green, Stylianos Basagiannis, and Andrey Sadovykh. 2016. Integrated tool chain for model-based design of Cyber-Physical Systems: The INTO-CPS project. In 2016 2nd International Workshop on Modelling, Analysis, and Control of Complex CPS (CPS Data). 1–6. https://doi.org/10.1109/CPSData.2016.7496424 [8] Salome Maro and Jan-Philipp Steghöfer. 2016. Capra: A Con�gurable and Extendable Traceability Management Tool. In 2016 IEEE 24th International Requirements Engineering Conference (RE). 407–408. https://doi.org/10.1109/RE.2016.19 [9] Shiva Nejati, Mehrdad Sabetzadeh, Davide Falessi, Lionel Briand, and Thierry Coq. 2012. A SysML-based approach to traceability management and design slicing in support of safety certi�cation: Framework, tool support, and case studies. Information and Software Technology 54, 6 (2012), 569–590.