Suitable properties for CONNECTed systems must be defined in rigorous formalized way in order to be used as a reference for CONNECTability analysis and monitoring. Elaborating on traditional, well-understood dependability metrics, a conceptual model has been first developed as a structured framework, which refines generic metrics into CONNECT-dependent and context-dependent metrics. These metrics apply to each of the four CONNECT actors: the Enabler (e.g., discovery, learning and synthesis), the CONNECTor, the Networked System, the CONNECTed system.

The elements and relations within this conceptual model have been then formalized into the CONNECT Property Meta-Model (CPMM), which provides a comprehensive machine-processable meta-model for all CONNECT-relevant non-functional properties and metrics. Fully following a model-driven transformational approach, CPMM provides a flexible notation that permits to keep the metrics definition separated from the specific system the property refers to. This descends from the observation that a metrics definition is application-independent and can be re-used for different systems. In other words, metrics can be defined once, stored in a repository and retrieved from it in case of need. Thus, by using CPMM, CONNECT users willing to specify a non-functional property need to (i) retrieve the required, or define new, metrics, (ii) specify the event the metrics apply to, and  finally (iii) specify the property to be analysed/monitored by binding the metrics to the event. By transformation these property models are then automatically translated into the expected input format for the CONNECT Enablers. For example, an implemented Model2Code Transformer translates CPMM properties into Drools Fusion rules for the GLIMPSE monitor, in the case of properties to be observed at run-time.
CPMM defines elements and types to specify prescriptive (required) and descriptive (owned) quantitative and qualitative properties that CONNECT actors may expose or must provide, respectively. The properties specified from this language might refer to the CONNECTed or the Networked System; they can serve as reference model requirements for the CONNECTor synthesis or as events to be observed by the monitoring Enabler during CONNECTor execution. Besides, the specified properties can also describe the characteristics owned by the Enablers. The key concepts of this meta-model are: Property, MetricsTemplate, Metrics, EventSet, and EventType. We separate the property definition from the application domain and its specific ontology. The ontology is linked to the Property meta-model via the EventType entity that models a generic event type where the terms of the application-domain ontology will be used.
CPMM is implemented as an eCore model into the Eclipse Modeling Framework. Moreover, an associated editor, released as an Eclipse Plugin, contains the information of the defined models and allows to create new model instances of the Property, Metrics, MetricsTemplate, EventType and EventSet meta-models. An excerpt of CPMM is provided below.

 

 

• The Builder module derives the dependability/performance model of the CONNECTed System from the specification provided by Synthesis.
• The Analyser module uses the model generated by Builder to perform a quantitative assessment of the non-functional requirements reported by the Discovery Enabler.
• The Evaluator module checks the analysis results to determine if the non-functional requirements are met:
•  If the requirements are satisfied, Evaluator reports to Synthesis that the CONNECTor can be successfully deployed, and reports to the Updater the aspects that must be observed for the CONNECTor that is going to be deployed, e.g., transition durations, and probability of transitions failure.
• If the requirements are not satisfied, Evaluator activates the Enhancer and/or Repairer module(s) to determine possible solutions to improve the dependability/performance level of the CONNECTed System.
• The Updater module interacts with the Monitor Enabler to refine the accuracy of model parameters through run-time observations, obtained through a continuous monitoring activity. Therefore, it provides adaptation of the pre-deployment analysis to cope with changes in, or inaccurate estimates of, model parameters.
• The Enhancer module is in charge of assessing whether the CONNECTor can be improved trough dependability mechanisms. It performs a form of pre-deployment adaptation to try to overcome deficiencies of the CONNECTor specification as revealed by the analysis. To accomplish its task, Enhancer is equipped with models representing basic dependability mechanisms suitable to contrast two typical classes of failure modes that may happen during interactions: timing failures, in which networked systems send messages at time instants that do not match an agreed schedule, and value failures, in which networked systems send messages containing incorrect information items.
• The Repairer module attempts to compute proper values for those parameters such that the new CONNECTor synthesised using the new values ensure that the non-functional properties are satisfied. Repairer adopts a variant of the Monte-Carlo sampling method to test a set of samples until it finds a good sample.

We are also working on an on-line quantitative verification approach dedicated to the case where the verification needs to be performed repeatedly with differing probability values, .e.g., provided by the Monitoring Enabler. Such runtime analysis can incur significant time and memory overheads. Our approach aims at improving the performance by reusing results from previous verifications to obtain fast accurate results, i.e., the results obtained in each round of verification are stored in order to avoid re-computation for the part of model that is not affected by probability changes. We also improve on efficiency of a probabilistic verification adopted in the approach, which typically requires a combination of graph-based analysis techniques and iterative numerical solution methods.

 

A generic lightweight architecture for monitoring, called GLIMPSE (Generic fLexIble Monitoring based on a Publish-Subscribe

infrastructure) has been developed.

Monitoring is conceived as a common core service offered to the other Enablers to detect conditions that they deem relevant, in order to implement feedback loops whereby approaches to dependability analysis,CONNECTor synthesis (shown in the picture below), and behaviour learning can be applied to an on-line setting and can be enhanced to cope with change and dynamism.