Safe Generation and Instrumentation of Runtime Verification Architectures

Method Purpose Short description of the method's purpose and main benefits

Method description A detailed description of the method

When making use of monitors in critical systems, it must be ensured that they neither negatively influence the security aspects of the original system nor affect the functional and the safety non-functional requirements of the system (e.g., task scheduling [IRVF1]). Guaranteeing that the deployment of such solutions does not negatively influence the dependability properties of systems can be overly complicated and time-consuming when no proper integration methods are used.

To abstract the formalities of correctly integrating monitoring architectures in the target system and reduce the steep learning curve associated with the usage of formal specification languages, which is common with RV based on formal specifications, we propose a new domain specific language (and associated tools) named MARS [IRVF2]. MARS will let developers focus what needs to be monitored instead of worrying about how to safely integrate such monitoring solutions to their target systems.

To achieve that, MARS will allow users to associate RV specifications with the components of a target system, providing support for a timing analysis over the combined system coupled with the instrumented monitors. MARS will ensure compliance with timeliness requirements and will support the generation of monitors from the formal specifications following a correct-by-construction approach. The generated monitors will be coupled with the target system via a runtime monitoring architecture that will link the interfaces of the system with those of the generated monitors.

Workflow used for the method on Runtime Verification using Formal Specifications

Method Strengths A listof the strengths of the method

Abstracts critical concepts that have a steep learning curve from the typical developer, allowing the focus to be on the specification of the monitors, not on their integration with a target system;
Possibility of increasing of the overall system reliability without compromising security and safety aspects, via a correct generation of monitors.

Method Limitations The limitations of the method

The use of runtime monitoring solutions inevitably implies extra overheads in the target system;
Designing a DSL to facilitate the formal specification of monitors can be tricky when such monitors get overly complex.

Method References Bibliography references to papers about the method.

[IRVF1] Khan, M. T., Serpanos, D., Shrobe, H. “A rigorous and efficient run-time security monitor for real-time critical embedded system applications.” In 2016 IEEE 3rd World Forum on Internet of Things (WF-IoT), 100–105. December 2016.

[IRVF2] G. S. Nandi, D. Pereira, J. Proença and E. Tovar, "Work-In-Progress: a DSL for the safe deployment of Runtime Monitors in Cyber-Physical Systems," 2020 IEEE Real-Time Systems Symposium (RTSS), 2020, pp. 395-398, doi: 10.1109/RTSS49844.2020.00047.

Method Dimensions

Evaluation Environment Type Type of environment where the method is applied. It can be more than one type of environment. (Dimension 1)

Evaluation Type Type of evaluation performed with that method. If a method is hybrid, more than one type can be selected. (Dimension 2)

Type of Component Under Evaluation Type of components that can be evaluated with that method. It can be more than one type. (Dimension 3)

Evaluation Stage The evaluation stage where the method is used. (Dimension 5)

Purpose of the Component Under Evaluation The type of purpose that can be evaluated by a method. It can be more than one type. (Dimension 6)

Type of Requirement Under Evaluation The type of requirements that a method is able to evaluate. It can be more than one type. (Dimension 7)

Evaluation Performance Indicator The type of evaluation criteria or KPI that a method is able to improve. It can be more than one type. (Dimension 8)

Relations

Related Methods A method could be related to other methods.

Tools A method can use zero or more tools.

Part Method A method (when it is a combination: Combination of method artefact that is a specialization of a V&V Method) could be composed of a set of V&V Methods.

Test Case or Verification and Validation activity Test Case or V&V activity performed in a Use Case. We will link to the method to the test cases where the method is used.

Standards A method can be linked with standards.

Context

Workflow

Contents

There are currently no items in this folder.