TOWARDS REQUIREMENTS REPRESENTATION USING AN EXTENSIVE ECA FORMALISM IN CYBER-PHYSICAL SYSTEMS

Requirement engineering has a critical role to play in the machinery for self-adaptation in Cyber-physical systems. Unfortunately, properties in the definition of requirements vanish as requirements are implemented and refined as a design artifact Synchronization the running systems and requirement models is implicit in current literatures as being short of introspection between different trade-offs implied in different architectural configurations. That is, keeping synchronization between requirements and software architecture is particularly significant in CPS systems. This tendency calls for revisiting the current requirement engineering by emphasizing on the understandability of the requirements to enhance the monitoring and measurement of requirements across the lifecycle. Current proposals suffer from the implementation of specific algorithmic solutions or applying in specific components and services. All in all then, the development of CPSs is being challenged with requirement-awareness across the whole lifecycle. To address the predicament, an ECARE formalism with the property value is proposed as a lightweight engineering tool for requirement elicitation and representation as a first step towards the requirement-aware development of CPSs.


Introduction Hua Wang and Jian Yu
ISSN (Print) : 2456-6411, ISSN (Online) : 2456-6403 Cyber-physical system (CPSs) is considered as the next generation of engineered systems in which an embedded computational entity monitors or controls engineered, physical and biological systems [1], applied in many important application domains such as medical health, navigation, transportation, energy, and environmental monitoring systems, etc.The need for enforcing selfconfigurable and self-adaptive behavior is identified, both at the level of software architecture and that of its components and services [2].Requirements for selfadaptive systems need to be run-time entities that can be reasoned about at run-time, which has received a body of research concern [3][4][5].CPS, being integrations of computation and physical processes, is a typical selfadaptive system because embedded computers and networks monitor and control the physical processes, usually with feedback loops where physical processes affect computations and vice versa [6].There is an urgent need to integrate semantic connections between requirement representations at design phrase and software architecture at runtime.That is, keeping synchronization between requirements and software architecture is particularly significant in CPS systems.On the one hand, changes in requirements should be reflected in software architecture to prevent it from deteriorating.Changes in runtime software architecture, on the other hand, should be checked to validate requirements not to be broken.This tendency calls for revisiting the current requirement engineering (RE) by emphasizing on the understandability of the requirements to enhance the monitoring and measurement of requirements across the lifecycle.
A multi-viewed approach for requirements engineering was proposed, representing each perspective [7].Traceability in RE becomes an important issue in the system development and evolution [8] because of the different contexts demanding different requirement trade-offs.Increasingly, the development of CPS is being challenged to account for a foundational and holistic way to tackle the requirement-awareness.Consequently, both the necessity of using the formalism method in requirement elicitation and effectiveness of building models to be used to requirement refinement have been a consensus in the literature [9][10][11].Unfortunately, properties in the definition of requirements vanish as requirements are implemented and refined as a design artifact.Recently, the RE community has concentrated on the requirement introspection method to adapt CPSs, i.e., the run-time requirement representation linking to the executing system.A formal approach to continuously assure non-functional requirements based on formal probabilistic models was proposed in [12].Data Acquisition component, and Data Storage and Combination component are used to support continuous requirements elicitation based on feedback and monitoring data [13].Researchers described initial works towards the realization of requirements-aware systems with REAssuRE, focusing on explicit representations of assumptions made at design time [14].Other literatures, such as building trustworthy requirements specification [15] and forum-based requirements elicitation process [16], focused on special application domains.
Most of the current proposals, however, suffer from limitations when considered in CPS scenarios despite of the promises and potentials of approaches because of their implementation of specific algorithmic solutions or applying in specific components and services, rather than tackling the issue of runtime requirement awareness in a holistic and comprehensive way.As a result, a lightweight framework is proposed in the paper to tackle the above predicament.The requirements representation based on ECA (Event-Condition-Action for REquirements) formalism could be easily observed and tracked, further reasoned about at run-time.The formalism is the ideal means to bridge the gap of requirements representation between the design-and runtime.Therefore, ECA is a natural candidate for RE supporting requirement-aware applications in CPS, i.e., changes in requirement could be reflected in software architecture on the one hand, evolution of software architecture at runtime, on the other hand, could be synchronized with the requirement model.As the first step, the appropriate requirement representation plays an important role in the above whole blueprint, which is the contribution of the paper.However, the traditional ECA rules fail to express additional semantics because it remains blurred to users what the actualintention of a policy is.For this reason, a beneficial extension is performed to get richer semantic information in an ECA requirement rule.
The paper is structured as follows.After expatiating on a motivating scenario in Subsection 2.1, the ECA RE formalism with property value is provided.By using Stimulus/Response Sequences (SRS) prototype, the standard requirement documents are generated in a seminatural language.In subsection 2.3, the transformation of SRS to ECA formalism is expounded and the RE implementation of the proposed model is discussed in Section 3. Finally, some conclusions and future works complete the paper.

RE property value
As a beneficial extension of our previous work [17], requirement definitions based on ECA formalism with RE the property value, on the one hand, employ notational shorthand for expressing requirements in a terse and practical way.On the other hand, the desired actions are specified in order to react to certain events.However, specifying a well-designed action based on the simple ECA requirement rule is inadequate to some important RE scenarios in the CPS system.For instance, it remains unclear whether the policy virtually leads to the desired effect after being executed or whether the effect would be counteracted by other actions.Being short of the extra semantic information presented in ECA requirement, RE such a rule calls for being revised to convey the actual desired intention while users performing the use-case (requirement rule), i.e., the additional information would be attached to the requirement rule to make it clear the effect of executing it.As a result, by employing the notion of Property Value (PV), the requirement rule would be enriched in a semantic way, allowing a requirement engineer to specify the use-case with the form "on event if condition triggers action with property value" by adding the PV to the classic ECA requirement rule.As a RE lightweight framework, the theoretical basis for ECA RE requirement rule is given in an extended version and tailored to our immediate purposes.We redefine and extend some primitive definitions of ECA requirement RE rule as follows.

A motivating scenario
To illustrate the proposed model, consider a motivating industry project.A Pervasive Health Management Director (PHmD) system for providing real-time personal health evaluations based on the medical health knowledge database by analyzing health data collected from remote wireless health devices, such as Blood Pressure Monitor, Electrocardiogram Measurement Instrument, Blood-glucose Meter and so on.Health service providers supply the health evaluation service based on QoS (Quality of Service) requirements subscribed by different customers who receive relevant services to monitor and improve their health level, as illustrated in Fig. 1.The health management and service system is deployed in Cyber-physical System based on cloud computing environment.The physical information collected from remote devices or wearable textiles is sent to PHmD system by means of wireless sensor networking technology.The expert system in PHmD is employed to analyze and process the individual physiological information applying underlying health knowledge warehouse.Then the risk evaluation is performed to know about the health level of customer.Eventually, home monitor, disease prevention, emergency rescue and remoting diagnose would bear the promising fruits cooperatively.

Terminologies and notations
The syntax hierarchy and terminology for the goal-driven ECARE formalism is listed in Table 1: A logical expression that, if satisfied or evaluated to be true, causes the action to be carried out.
Consists of updates or invocations to change the status of the target system and accomplish the objects of stakeholders.
Formulates the result value after performing the action to denote the effect of the use case on the status of the target system.The conjunction operation of events The disjunction operation of events

Mutually exclusive events
Events occurrence in accordance with a certain sequence The negative of an event The repeated occurrence of n times Definition 4.An action could be a composite one using some constructors, such as Fellow, Alternative and Iteration explained in [17].To illustrate how the proposed formalism described above works in practice, let us consider the following requirement scenario for our PHmD.According to IEEE Recommended Practice for Software Requirements Specifications, the requirement scenario is described using Stimulus/Response Sequences (SRS) prototype.
The SRS method provides the powerful understandability of the requirements in favor of discussion with customers.As a part of PHmD system requirements, Jogging Monitor specifies the Device (Wearable Textiles) communicating with the Node (Health App.) hosted in wireless cellphones, shown in Table 3.

High
Monitor the vital sign of the jogger, the abnormity, if any, will be informed to the jogger.
1.While jogging, the wearable device is on.
2. The data of Blood Pressure, Body Temperature, Respiratory Frequency and Oxygen Consumption are measured in the wearable device every 20 seconds.3.And these Vital Signs are to be transferred to the hosting Mobile App. 4. After analysis, an abnormality, if any, will be sent to the jogger.
The jogger takes actions according to the analysis report.
The example SRS model is based on the fruits of the software requirements specification process and results in an unambiguous and complete requirements specification document.The benefits of relevant stakeholders could be balanced, thus bringing requirements closer to the actual the requirement model the stakeholders have in mind.
Although, as the first step toward realizing the requirements introspection at runtime in Cyber-physical Systems, the SRS model provides a starting point to design and implement requirements, the refinement activity is indispensable according to the predefined guidelines.The ECARE formalism determines how the system should react if something happens, therefore, it is quite natural that the subsequent refinement activity is performed by the transforming the SRS model to the corresponding ECAREformalism.

Transforming SRS to ECARE formalism
To make the goal of the requirement operationalized into tasks and domain assumptions, the above SRS specifications should be transformed into an ECARE formalism as the first step in requirements refinement.A transformational paradigm should be able to parse the semi-natural language requirements like the example SRS.Formally, an SRS requirement is defined as a set of sequential words or phrases: , , , where, Zi denotes a word or phrase in the current SRS requirement descriptions.To get ECARE formalism, the engineering stepwise process is defined below.

1) Concern elicitation and lexicon identification
Concerns describe key features and characteristics of the system under consideration, while lexicons symbolize the domain assumption and the core concept.The first arrangement of transforming SRS to ECA formalism is RE to elicit concerns and identify lexicons.Concerns concentrate on objects, goals, tasks and their corresponding properties, while lexicons refer to find appropriate words or terms to present concerns in domain assumptions.As a result, pattern matching will play an important role in this stage.Formally, a matching rule in a statement of SRS requirements is a serial of lexicons by applying the master template as follows: where, is the set of sequential words or phrases in the Â statement of SRS document and the pattern is the matching rule in MTsyn, defined as follows.Suppose a where, p means each different lexicon is matched with the member in MT , i.e., there exist multiple possible syn matches.

2) Lexical substitution
While parsing the sequence SRS , a set of semantic RE notations is assigned to each word or phrase, which establishes a lexical set mapping from a certain domain term to the corresponding synonym.Formally, the lexical set is defined as the hash pair: where, Z has the synonym set Z. In the case of the SRS i scenario, the lexical set could be matching function is P = {V , V , ..., V } then a complete

3) Syntactic Parsing
A different parsing pattern in a SRSRE context could be decided according to structural features for parsing goal in a sentence, such as bullets, numberings, headings (subheadings) and sectional structure, etc.With the purpose of choosing, a utility function is employed to decide on which is the matching one.The total utility function, TUF, computes the utility according to the relative weight between multiple matches.The relative weigh, W, is defined below.where, each match has a utility value, MUV , assigned i with a value between 0 and 1.The aggregate utility can be computed by using the distance vector in a branch section.Given any term t, with subsection, subset(t), the aggregate utility (AU) recursively computes the distance weight:

Implementation
In the proposed method, a semi-automated tool has been developed to support transforming SRS to ECA formalism.In the RE case of our above SRS scenario, the corresponding ECA formalism is generated by applying such a transformational RE paradigm as depictedin Fig. 3. Fig. 3 : The ECARE formalism of the example scenario In the example scenario, the action seq Action_Collect represents a sequence of actions, that is, measuring data of Blood Pressure, Body Temperature, Respiratory Frequency and Oxygen Consumption every 20 seconds.These actions could be activated simultaneously if wearable devices are switched on when someone is jogging.In this way, the requirements could be elicited succinctly and lays a formal basis on successive analysis and refinement.

Conclusion and future works
As a first step, requirements elicitation and representation launches a software lifecycle, exposing important system characteristics and properties in the early phase of software engineering of CPSs.Increasingly, CPSs host in a dynamic operational environment requiring that adaptive actions are performed while predefined events occur to keep CPSs from exacerbation over time.The changeability of system requirements raises a claim that requirements should be sensitive to the context where CPSs must operate.Changes of requirements should be synchronized with the running systems, i.e., when requirements change, the computational reflection should be showed at runtime.In addition, changes in software architecture should be reflected into requirement artifacts.All in all then, the development of CPSs is being challenged with requirement-awareness across the whole lifecycle.To address the issue, an ECARE formalism with the property value is proposed as a lightweight engineering tool for requirement elicitation and representation to meet the above the challenge.An illustrative example shows the efficiency of the proposed formalism.
However, conflicts will still arise if the output actions bring the requirements into an inconsistent status.We need to extend the principles that allow advanced conflict resolution.Future works include borrowing techniques and toolsfrom interdiscipline to address the conflict issue, such as machine learning.In addition, the refinement process of the ECARE formalism and its animation should be studied further continuously by employing the theory of Labelled Transition System (LTA).Also, we plan to carry out more performance studies which are needed to ensure that the model does scale to complicated environments.

Fig. 2 :
Fig. 2: The meta-model of requirementsbased on goal-driven ECARE formalism parsing algorithm rests on AU and the remainder of being not parsed in the current statement as follows.(tj ) ¹ AE ISSN (Print) : 2456-6411, ISSN (Online) : 2456-6403

Table 1
The syntax hierarchy and terminology of ECARE Definition 2.A requirement rule is a four-tuple ReRule = <E, C, A, PV> lue represents the influence on an entity of the adapted system after executing an ECA requirement RE rule, that is, the goal the requirement rule intends to achieve.And all these four parts of a requirement rule are required.
Definition 1.The goal-driven ECA formalism based RE software requirements for a runtime requirement monitor is a triple ECA = <Id,ReRule,W>, where Id is the RE identifier of the requirement rule; ReRule-{r | i = 12,....,n} i is a requirement rule for requirement elicitation defined in Definition 2 as follows; and W is an event and requirement rule warehouse.

Table 2
Event operators