In this training submodule we outline the core workings of the MILS Adaptation System (for details please refer to the project deliverable D4.3 [1]) and we describe how to create the artifacts which are taken as input by the MILS Adaptation System. Specifically, we focus on the Adaptation Engine, the core component of the MILS Adaptation System.
Key elements
Dynamic Distributed MILS platform
Dynamic MILS platform with deterministic networking
Mechanisms for dynamic reconfiguration and configuration introspection
Declarative dynamic architecture modeling and verification
Language to describe reconfigurable systems architecture, component models, failure models and fault propagation
Theory and framework for dynamic reconfiguration
Theory and framework for adaptation
Language to express critical properties to be verified
Compositional verification framework
Monitoring, Adaptation, Configuration, & Certification Assurance Planes
Assurance-based security evaluation methodology and runtime mechanisms for just-in-time certification of adaptive systems
CITADEL configuration and reconfiguration synthesisRamnGonzlezRuiz2
This material provides a thorough presentation of the CITADEL Reconfiguration Plane, hereafter denoted XP, from high-level design to low-level implementation and deployment on the CITADEL platform.
This document provides an overview of state monitoring in the context of the CITADEL project. It discusses the monitoring plane and how it is used to monitor components in the operational plane and resources in the foundational plane. It also describes how the Kaspersky Security System can be used for state monitoring by specifying monitoring policies and integrating them with the system modeling framework. The document outlines different sources of monitoring data and policies and how a layered implementation approach separates concerns between the monitoring, operational, and foundational planes.
This document describes the modeling, testing, and verification of system models which are used by
the MILS Adaptation System. Several example models are provided in this document, with one of
them developed in a step-by-step manner. Video demonstrations which accompany this document
demonstrate the use of supporting tools.
This training module overviews the role, interfaces, structure and functionality of the Adaptation Plane, and explains how to start the components which comprise the Adaptation Plane. The module focuses on the information necessary to understand the start-up and operation of the Adaptation
Plane, which is needed in order to deploy the Adaptation Plane as part of the CITADEL Platform.
This document provides an overview of communications monitoring within the CITADEL framework. It discusses various monitoring methods including signature-based monitoring, white-box anomaly detection, and association rules. Signature-based monitoring specifies known malicious situations as signatures to detect. White-box anomaly detection learns a model of normal communications and flags deviations as anomalous. The document also describes how monitoring interacts with the specification and other CITADEL planes.
This material provides guidelines in form of a presentation of the Context Awareness - component of the Adaptation Plane.
The Context Awareness is a component which implements a mechanism to identify the current context under which the CITADEL framework as well as an application is used/operated.
To identify the current context, the Context Awareness will use run-time data provided by the Monitoring Plane as input on one hand and a pre-defined context model on the other hand.
The document discusses the Adaptive MILS Evidential Tool Bus (AM-ETB) which is used to create and maintain certification evidence for adaptive MILS systems. The AM-ETB uses assurance case patterns to develop modular assurance cases. It coordinates the execution of verification tools to generate evidence and update assurance cases. The AM-ETB implementation includes a pattern repository, evidence repository, workflow engine, tool agents, and assurance case repository.
Key elements
Dynamic Distributed MILS platform
Dynamic MILS platform with deterministic networking
Mechanisms for dynamic reconfiguration and configuration introspection
Declarative dynamic architecture modeling and verification
Language to describe reconfigurable systems architecture, component models, failure models and fault propagation
Theory and framework for dynamic reconfiguration
Theory and framework for adaptation
Language to express critical properties to be verified
Compositional verification framework
Monitoring, Adaptation, Configuration, & Certification Assurance Planes
Assurance-based security evaluation methodology and runtime mechanisms for just-in-time certification of adaptive systems
CITADEL configuration and reconfiguration synthesisRamnGonzlezRuiz2
This material provides a thorough presentation of the CITADEL Reconfiguration Plane, hereafter denoted XP, from high-level design to low-level implementation and deployment on the CITADEL platform.
This document provides an overview of state monitoring in the context of the CITADEL project. It discusses the monitoring plane and how it is used to monitor components in the operational plane and resources in the foundational plane. It also describes how the Kaspersky Security System can be used for state monitoring by specifying monitoring policies and integrating them with the system modeling framework. The document outlines different sources of monitoring data and policies and how a layered implementation approach separates concerns between the monitoring, operational, and foundational planes.
This document describes the modeling, testing, and verification of system models which are used by
the MILS Adaptation System. Several example models are provided in this document, with one of
them developed in a step-by-step manner. Video demonstrations which accompany this document
demonstrate the use of supporting tools.
This training module overviews the role, interfaces, structure and functionality of the Adaptation Plane, and explains how to start the components which comprise the Adaptation Plane. The module focuses on the information necessary to understand the start-up and operation of the Adaptation
Plane, which is needed in order to deploy the Adaptation Plane as part of the CITADEL Platform.
This document provides an overview of communications monitoring within the CITADEL framework. It discusses various monitoring methods including signature-based monitoring, white-box anomaly detection, and association rules. Signature-based monitoring specifies known malicious situations as signatures to detect. White-box anomaly detection learns a model of normal communications and flags deviations as anomalous. The document also describes how monitoring interacts with the specification and other CITADEL planes.
This material provides guidelines in form of a presentation of the Context Awareness - component of the Adaptation Plane.
The Context Awareness is a component which implements a mechanism to identify the current context under which the CITADEL framework as well as an application is used/operated.
To identify the current context, the Context Awareness will use run-time data provided by the Monitoring Plane as input on one hand and a pre-defined context model on the other hand.
The document discusses the Adaptive MILS Evidential Tool Bus (AM-ETB) which is used to create and maintain certification evidence for adaptive MILS systems. The AM-ETB uses assurance case patterns to develop modular assurance cases. It coordinates the execution of verification tools to generate evidence and update assurance cases. The AM-ETB implementation includes a pattern repository, evidence repository, workflow engine, tool agents, and assurance case repository.
This document discusses software modeling and verification using formal methods. It provides an introduction to formal methods, their motivation and applications. It then discusses the role of formal methods in the CITADEL project, including modeling dynamic architectures, specification of monitors and properties, verification, monitor synthesis, adaptation and assurance case generation. Key aspects of modeling dynamic architectures in CITADEL are parametrized architecture modeling, dynamic architecture modeling, specification of monitors and properties.
This document discusses configuring communications monitoring by implementing features and signatures from network traffic and learning a white-box model. It describes extracting feature values from packet fields using Python expressions and gathering them in a feature file. Signatures are defined as Python boolean expressions mapped to alert IDs. A white-box model is learned from a training set and stored in a histograms file, which can be tuned by adjusting likelihood values and bins. The steps are demonstrated on a bottle filling plant use case monitoring Modbus traffic.
This document discusses the configuration of a state monitoring module. It describes generating monitors for components, sensors for input ports, and converting monitoring properties into policies. The document also outlines the monitoring library generator, generic and CITADEL APIs, supported SLIM types and operators, and examples of initialization and monitoring loops.
Fault tolerance is an important issue in the field of cloud computing which is concerned with the techniques or mechanism needed to enable a system to tolerate the faults that may encounter during its functioning. Fault tolerance policy can be categorized into three categories viz. proactive, reactive and adaptive. Providing a systematic solution the loss can be minimized and guarantee the availability and reliability of the critical services. The purpose and scope of this study is to recommend Support Vector Machine, a supervised machine learning algorithm to proactively monitor the fault so as to increase the availability and reliability by combining the strength of machine learning algorithm with cloud computing.
Proactive cloud service assurance framework for fault remediation in cloud en...IJECEIAES
Cloud resiliency is an important issue in successful implementation of cloud computing systems. Handling cloud faults proactively, with a suitable remediation technique having minimum cost is an important requirement for a fault management system. The selection of best applicable remediation technique is a decision making problem and considers parameters such as i) Impact of remediation technique ii) Overhead of remediation technique ii) Severity of fault and iv) Priority of the application. This manuscript proposes an analytical model to measure the effectiveness of a remediation technique for various categories of faults, further it demonstrates the implementation of an efficient fault remediation system using a rulebased expert system. The expert system is designed to compute a utility value for each remediation technique in a novel way and select the best remediation technique from its knowledgebase. A prototype is developed for experimentation purpose and the results shows improved availability with less overhead as compared to a reactive fault management system.
The document discusses three main approaches to achieving software fault tolerance:
1) Recovery blocks, where variants are executed sequentially and an acceptance test is applied.
2) N-version programming, where variants are executed in parallel and their results are voted on.
3) N self-checking programming, where self-checking components made of variants with comparison or acceptance tests execute in parallel. Most real-life systems use the self-checking approach.
The approaches are analyzed in terms of dependability, costs, and sources of overhead. Recovery blocks have sequential execution while N-version programming and N self-checking programming have parallel execution. N self-checking programming relies on individual components for results while N-version programming has cooperative
The Role of Architectural Model Checking in Conducting Preliminary Safety Ass...Omar Jaradat
The document discusses using architectural model checking to help satisfy preliminary safety assessment obligations from ISO 26262. It applies model checking to an AADL model of a fuel level estimation system to validate properties. This partially satisfies ISO 26262 objectives by identifying issues. While useful, model checking must be complemented with other verification methods to fully satisfy objectives. The document demonstrates how model checking can contribute to a safety assessment and ISO 26262 conformance argument.
The document summarizes topics related to real-time software engineering including embedded system design, architectural patterns for real-time software, timing analysis, and real-time operating systems. It discusses key characteristics of embedded systems like responsiveness, the need to respond to stimuli within specified time constraints, and how real-time systems are often modeled as cooperating processes controlled by a real-time executive. The document also outlines common architectural patterns for real-time systems including observe and react, environmental control, and process pipeline.
Guaranteed Component Assembly with Round Trip Analysis for Energy Efficient H...Ákos Horváth
The document discusses the CONCERTO project, which builds upon the CHESS project to further develop model-driven engineering techniques for designing multi-concern software components across several domains including telecom, aerospace, automotive, petroleum, and medical. The project aims to enhance the multi-concern component methodology and toolset defined in CHESS to support additional domains like telecare through techniques such as property-preserving implementation, model execution, safety modeling, and support for multicore targets and resource partitioning. A telecare demonstrator is presented as an initial application of the round-trip modeling and analysis approach.
This document discusses simulation-based software development for time-triggered communication systems like FlexRay, which are commonly used in automotive applications. It introduces an approach using the SIDERA simulation system to develop and test application software on simulated communication controllers. This allows accelerating the software development process by eliminating delays from compiling and loading code onto hardware and easing debugging in distributed real-time systems. The goal is to enable executing host applications on simulated FlexRay controllers without requiring actual hardware or modifying the original code.
The European Space Agency (ESA) uses an engine to perform tests in the Ground Segment infrastructure, specially the Operational Simulator. This engine uses many different tools to ensure the development of regression testing infrastructure and these tests perform black-box testing to the C++ simulator implementation. VST (VisionSpace Technologies) is one of the companies that provides these services to ESA and they need a tool to infer automatically tests from the existing C++ code, instead of writing manually scripts to perform tests. With this motivation in mind, this paper explores automatic testing approaches and tools in order to propose a system that satisfies VST needs.
A SIMULATION APPROACH TO PREDICATE THE RELIABILITY OF A PERVASIVE SOFTWARE SY...Osama M. Khaled
This document discusses simulating a pervasive software system to predict its reliability. It begins by introducing pervasive computing and its importance. It then describes the reference architecture model, which includes a smart environment conceptual model, smart object model, and pervasive system architecture model. The document outlines the simulation approach, including scenarios, specifications of simulation entities, assumptions, and extreme assumptions. The simulation aims to predict reliability and availability under different scenarios and control variable values. Key metrics like MTBF and MTTR will be measured to calculate reliability and availability.
This document summarizes a software engineering solved paper from June 2013. It discusses various topics in software engineering including attributes of good software, definitions of software engineering and different types of software products, emergent system properties with examples, critical systems and their types, the Rational Unified Process (RUP) methodology with block diagrams, security terminology, and metrics for specifying non-functional requirements. The requirement engineering process is also explained with the main goal being to create and maintain a system requirement document through various sub-processes like feasibility study, elicitation and analysis, validation, and management of requirements.
High-Performance Timing Simulation of Embedded SoftwareMr. Chanuwan
This paper presents a hybrid approach for high-performance timing simulation of embedded software. The approach combines static execution time analysis and back-annotation of timing information into a SystemC model. In the first step, static timing analysis determines the cycle count for each basic block using processor models. This timing information is then back-annotated into SystemC. Dynamic effects like branches and caches are handled by instrumentation code. The generated code can be simulated with 90% of the speed of untimed software. This hybrid approach aims to achieve fast and accurate timing simulation of embedded software.
This document discusses exception handling in software programs. It begins by defining key concepts like program specification, semantics, exceptions, correctness and failures. It notes that exceptions occur when a program cannot provide its standard service due to circumstances outside its standard domain. The document then discusses how exceptions are handled, focusing on termination mechanisms where signaling an exception terminates execution, versus resumption mechanisms where execution resumes after handling. It argues termination mechanisms are superior as they better support modularity and recovering consistent states. The remainder of the document will examine exception handling for hierarchical modular programs using termination mechanisms.
A new design for fault tolerant and fault recoverable ALU System has been proposed in this paper. Reliability is one of the most critical factors that have to be considered during the designing phase of any IC. In critical applications like Medical equipment & Military applications this reliability factor plays a
very critical role in determining the acceptance of product. Insertion of special modules in the main design for reliability enhancement will give considerable amount of area & power penalty. So, a novel approach to this problem is to find ways for reusing the already available components in digital system in efficient way to implement recoverable methodologies. Triple Modular Redundancy (TMR) has traditionally used
for protecting digital logic from the SEUs (single event upset) by triplicating the critical components of the system to give fault tolerance to system. ScTMR- Scan chain-based error recovery TMR technique provides recovery for all internal faults. ScTMR uses a roll-forward approach and employs the scan chain implemented in the circuits for testability purposes to recover the system to fault-free state. The proposed
design will incorporate a ScTMR controller over TMR system of ALU and will make the system fault tolerant and fault recoverable. Hence, proposed design will be more efficient & reliable to use in critical applications, than any other design present till today.
This document is a master's thesis that investigates connecting process models built in MATLAB/Simulink to controllers implemented in ABB's Soft Controller. The connection is made via ABB's OPC-MMS server and a gateway application. The author conducts various tests to determine if real-time simulations are possible. The simulations work as expected if users are aware of delays from different sampling stages. This allows for easy testing of function blocks and control modules from ABB's Control Builder. It also enables demonstrating potential improvements to customers' control systems. The thesis provides background on relevant topics like ABB's distributed control system components, real-time operating systems, Windows programming, and timers.
The document describes an algorithm for tolerating crash failures in distributed systems called the algorithm of mutual suspicion (AMS). AMS allows the backbone of a distributed application to tolerate failures of up to n-1 of its n components. Each node runs one agent of the backbone consisting of 3 tasks: D for the system database, I for monitoring "I'm alive" signals, and R for error recovery. The coordinator periodically sends "I'm alive" messages and assistants reply with acknowledgments. If a node does not receive the expected messages, it enters a suspicion period and may deduce a crashed component and initiate recovery actions.
The document summarizes the module decomposition structure of the A-7E software. It describes the three highest-level modules: the Hardware-Hiding Module, which implements virtual hardware; the Behavior-Hiding Module, which determines output values based on requirements; and the Software Decision Module, which hides software design decisions. It then provides examples of lower-level modules, including the Application Data Type Module, which defines useful data types; the Data Banker Module, which determines when data values are updated; and the Filter Behavior Module, which contains digital models of physical filters.
This document describes a project that aims to demonstrate computational offloading using a robot built with Lego Mindstorms EV3 parts. The robot will perform face tracking using a webcam and offload parts of the face tracking algorithm when the CPU becomes overloaded. A GUI will allow the user to manually trigger offloading and view its effects. The project aims to explore how offloading can improve responsiveness for low-power systems like robots.
This thesis introduces CloudML, a domain-specific language for model-based provisioning of cloud applications. CloudML aims to address inconsistencies between different cloud providers' APIs and provisioning methods. The thesis presents the design and implementation of CloudML, including its meta-model and how it supports defining topologies and provisioning nodes across multiple clouds. Experiments were conducted using CloudML to provision applications on Amazon Web Services and Rackspace to validate the approach. The thesis discusses perspectives and future work, such as integrating load balancing and automated scaling into CloudML models.
The document is a report submitted by Priya Hada to Ms. Pushpa Gotwal on PLC and SCADA. It includes a certificate signed by Mr. Sudhir Kumar Mishra confirming Priya completed the work. The report contains an introduction to automation, PLCs, and SCADA. It discusses the history and features of PLCs, and provides examples of ladder logic programming. It also covers the architecture, communications, interfacing and applications of SCADA systems.
This document discusses software modeling and verification using formal methods. It provides an introduction to formal methods, their motivation and applications. It then discusses the role of formal methods in the CITADEL project, including modeling dynamic architectures, specification of monitors and properties, verification, monitor synthesis, adaptation and assurance case generation. Key aspects of modeling dynamic architectures in CITADEL are parametrized architecture modeling, dynamic architecture modeling, specification of monitors and properties.
This document discusses configuring communications monitoring by implementing features and signatures from network traffic and learning a white-box model. It describes extracting feature values from packet fields using Python expressions and gathering them in a feature file. Signatures are defined as Python boolean expressions mapped to alert IDs. A white-box model is learned from a training set and stored in a histograms file, which can be tuned by adjusting likelihood values and bins. The steps are demonstrated on a bottle filling plant use case monitoring Modbus traffic.
This document discusses the configuration of a state monitoring module. It describes generating monitors for components, sensors for input ports, and converting monitoring properties into policies. The document also outlines the monitoring library generator, generic and CITADEL APIs, supported SLIM types and operators, and examples of initialization and monitoring loops.
Fault tolerance is an important issue in the field of cloud computing which is concerned with the techniques or mechanism needed to enable a system to tolerate the faults that may encounter during its functioning. Fault tolerance policy can be categorized into three categories viz. proactive, reactive and adaptive. Providing a systematic solution the loss can be minimized and guarantee the availability and reliability of the critical services. The purpose and scope of this study is to recommend Support Vector Machine, a supervised machine learning algorithm to proactively monitor the fault so as to increase the availability and reliability by combining the strength of machine learning algorithm with cloud computing.
Proactive cloud service assurance framework for fault remediation in cloud en...IJECEIAES
Cloud resiliency is an important issue in successful implementation of cloud computing systems. Handling cloud faults proactively, with a suitable remediation technique having minimum cost is an important requirement for a fault management system. The selection of best applicable remediation technique is a decision making problem and considers parameters such as i) Impact of remediation technique ii) Overhead of remediation technique ii) Severity of fault and iv) Priority of the application. This manuscript proposes an analytical model to measure the effectiveness of a remediation technique for various categories of faults, further it demonstrates the implementation of an efficient fault remediation system using a rulebased expert system. The expert system is designed to compute a utility value for each remediation technique in a novel way and select the best remediation technique from its knowledgebase. A prototype is developed for experimentation purpose and the results shows improved availability with less overhead as compared to a reactive fault management system.
The document discusses three main approaches to achieving software fault tolerance:
1) Recovery blocks, where variants are executed sequentially and an acceptance test is applied.
2) N-version programming, where variants are executed in parallel and their results are voted on.
3) N self-checking programming, where self-checking components made of variants with comparison or acceptance tests execute in parallel. Most real-life systems use the self-checking approach.
The approaches are analyzed in terms of dependability, costs, and sources of overhead. Recovery blocks have sequential execution while N-version programming and N self-checking programming have parallel execution. N self-checking programming relies on individual components for results while N-version programming has cooperative
The Role of Architectural Model Checking in Conducting Preliminary Safety Ass...Omar Jaradat
The document discusses using architectural model checking to help satisfy preliminary safety assessment obligations from ISO 26262. It applies model checking to an AADL model of a fuel level estimation system to validate properties. This partially satisfies ISO 26262 objectives by identifying issues. While useful, model checking must be complemented with other verification methods to fully satisfy objectives. The document demonstrates how model checking can contribute to a safety assessment and ISO 26262 conformance argument.
The document summarizes topics related to real-time software engineering including embedded system design, architectural patterns for real-time software, timing analysis, and real-time operating systems. It discusses key characteristics of embedded systems like responsiveness, the need to respond to stimuli within specified time constraints, and how real-time systems are often modeled as cooperating processes controlled by a real-time executive. The document also outlines common architectural patterns for real-time systems including observe and react, environmental control, and process pipeline.
Guaranteed Component Assembly with Round Trip Analysis for Energy Efficient H...Ákos Horváth
The document discusses the CONCERTO project, which builds upon the CHESS project to further develop model-driven engineering techniques for designing multi-concern software components across several domains including telecom, aerospace, automotive, petroleum, and medical. The project aims to enhance the multi-concern component methodology and toolset defined in CHESS to support additional domains like telecare through techniques such as property-preserving implementation, model execution, safety modeling, and support for multicore targets and resource partitioning. A telecare demonstrator is presented as an initial application of the round-trip modeling and analysis approach.
This document discusses simulation-based software development for time-triggered communication systems like FlexRay, which are commonly used in automotive applications. It introduces an approach using the SIDERA simulation system to develop and test application software on simulated communication controllers. This allows accelerating the software development process by eliminating delays from compiling and loading code onto hardware and easing debugging in distributed real-time systems. The goal is to enable executing host applications on simulated FlexRay controllers without requiring actual hardware or modifying the original code.
The European Space Agency (ESA) uses an engine to perform tests in the Ground Segment infrastructure, specially the Operational Simulator. This engine uses many different tools to ensure the development of regression testing infrastructure and these tests perform black-box testing to the C++ simulator implementation. VST (VisionSpace Technologies) is one of the companies that provides these services to ESA and they need a tool to infer automatically tests from the existing C++ code, instead of writing manually scripts to perform tests. With this motivation in mind, this paper explores automatic testing approaches and tools in order to propose a system that satisfies VST needs.
A SIMULATION APPROACH TO PREDICATE THE RELIABILITY OF A PERVASIVE SOFTWARE SY...Osama M. Khaled
This document discusses simulating a pervasive software system to predict its reliability. It begins by introducing pervasive computing and its importance. It then describes the reference architecture model, which includes a smart environment conceptual model, smart object model, and pervasive system architecture model. The document outlines the simulation approach, including scenarios, specifications of simulation entities, assumptions, and extreme assumptions. The simulation aims to predict reliability and availability under different scenarios and control variable values. Key metrics like MTBF and MTTR will be measured to calculate reliability and availability.
This document summarizes a software engineering solved paper from June 2013. It discusses various topics in software engineering including attributes of good software, definitions of software engineering and different types of software products, emergent system properties with examples, critical systems and their types, the Rational Unified Process (RUP) methodology with block diagrams, security terminology, and metrics for specifying non-functional requirements. The requirement engineering process is also explained with the main goal being to create and maintain a system requirement document through various sub-processes like feasibility study, elicitation and analysis, validation, and management of requirements.
High-Performance Timing Simulation of Embedded SoftwareMr. Chanuwan
This paper presents a hybrid approach for high-performance timing simulation of embedded software. The approach combines static execution time analysis and back-annotation of timing information into a SystemC model. In the first step, static timing analysis determines the cycle count for each basic block using processor models. This timing information is then back-annotated into SystemC. Dynamic effects like branches and caches are handled by instrumentation code. The generated code can be simulated with 90% of the speed of untimed software. This hybrid approach aims to achieve fast and accurate timing simulation of embedded software.
This document discusses exception handling in software programs. It begins by defining key concepts like program specification, semantics, exceptions, correctness and failures. It notes that exceptions occur when a program cannot provide its standard service due to circumstances outside its standard domain. The document then discusses how exceptions are handled, focusing on termination mechanisms where signaling an exception terminates execution, versus resumption mechanisms where execution resumes after handling. It argues termination mechanisms are superior as they better support modularity and recovering consistent states. The remainder of the document will examine exception handling for hierarchical modular programs using termination mechanisms.
A new design for fault tolerant and fault recoverable ALU System has been proposed in this paper. Reliability is one of the most critical factors that have to be considered during the designing phase of any IC. In critical applications like Medical equipment & Military applications this reliability factor plays a
very critical role in determining the acceptance of product. Insertion of special modules in the main design for reliability enhancement will give considerable amount of area & power penalty. So, a novel approach to this problem is to find ways for reusing the already available components in digital system in efficient way to implement recoverable methodologies. Triple Modular Redundancy (TMR) has traditionally used
for protecting digital logic from the SEUs (single event upset) by triplicating the critical components of the system to give fault tolerance to system. ScTMR- Scan chain-based error recovery TMR technique provides recovery for all internal faults. ScTMR uses a roll-forward approach and employs the scan chain implemented in the circuits for testability purposes to recover the system to fault-free state. The proposed
design will incorporate a ScTMR controller over TMR system of ALU and will make the system fault tolerant and fault recoverable. Hence, proposed design will be more efficient & reliable to use in critical applications, than any other design present till today.
This document is a master's thesis that investigates connecting process models built in MATLAB/Simulink to controllers implemented in ABB's Soft Controller. The connection is made via ABB's OPC-MMS server and a gateway application. The author conducts various tests to determine if real-time simulations are possible. The simulations work as expected if users are aware of delays from different sampling stages. This allows for easy testing of function blocks and control modules from ABB's Control Builder. It also enables demonstrating potential improvements to customers' control systems. The thesis provides background on relevant topics like ABB's distributed control system components, real-time operating systems, Windows programming, and timers.
The document describes an algorithm for tolerating crash failures in distributed systems called the algorithm of mutual suspicion (AMS). AMS allows the backbone of a distributed application to tolerate failures of up to n-1 of its n components. Each node runs one agent of the backbone consisting of 3 tasks: D for the system database, I for monitoring "I'm alive" signals, and R for error recovery. The coordinator periodically sends "I'm alive" messages and assistants reply with acknowledgments. If a node does not receive the expected messages, it enters a suspicion period and may deduce a crashed component and initiate recovery actions.
The document summarizes the module decomposition structure of the A-7E software. It describes the three highest-level modules: the Hardware-Hiding Module, which implements virtual hardware; the Behavior-Hiding Module, which determines output values based on requirements; and the Software Decision Module, which hides software design decisions. It then provides examples of lower-level modules, including the Application Data Type Module, which defines useful data types; the Data Banker Module, which determines when data values are updated; and the Filter Behavior Module, which contains digital models of physical filters.
This document describes a project that aims to demonstrate computational offloading using a robot built with Lego Mindstorms EV3 parts. The robot will perform face tracking using a webcam and offload parts of the face tracking algorithm when the CPU becomes overloaded. A GUI will allow the user to manually trigger offloading and view its effects. The project aims to explore how offloading can improve responsiveness for low-power systems like robots.
This thesis introduces CloudML, a domain-specific language for model-based provisioning of cloud applications. CloudML aims to address inconsistencies between different cloud providers' APIs and provisioning methods. The thesis presents the design and implementation of CloudML, including its meta-model and how it supports defining topologies and provisioning nodes across multiple clouds. Experiments were conducted using CloudML to provision applications on Amazon Web Services and Rackspace to validate the approach. The thesis discusses perspectives and future work, such as integrating load balancing and automated scaling into CloudML models.
The document is a report submitted by Priya Hada to Ms. Pushpa Gotwal on PLC and SCADA. It includes a certificate signed by Mr. Sudhir Kumar Mishra confirming Priya completed the work. The report contains an introduction to automation, PLCs, and SCADA. It discusses the history and features of PLCs, and provides examples of ladder logic programming. It also covers the architecture, communications, interfacing and applications of SCADA systems.
Communication and Control in Electric Power Systems_ Applications of Parallel...alimeziane3
Communication and Control in Electric Power Systems_ Applications of Parallel and Distributed Processing (IEEE Press Series on Power Engineering) ( PDFDrive ).pdf
This document describes a student project to develop an affordable environmental monitoring and controlling system for greenhouses. It aims to create a low-cost wireless sensor network using sensor nodes to measure factors like temperature, humidity, and soil moisture. The sensor data will be sent to a centralized server and displayed on a web interface to allow remote monitoring. Farmers will be able to view real-time sensor readings and historical data charts to help control the greenhouse environment and improve crop yields. The project aims to address the need for affordable sensor systems for farmers in developing countries like Sri Lanka.
This document provides an abstract for a bachelor thesis that compares the SCADA protocols IEC 60870-5-104 and MQTT. The thesis includes:
1) An overview and evaluation of several SCADA protocols, including IEC 60870-5-104 and MQTT.
2) Experimental implementations of IEC 60870-5-104 and MQTT in a smart grid simulation created with the Mosaik framework.
3) An evaluation of the implementations and a conclusion that MQTT has potential for smart grid SCADA systems that need to interact with IoT devices, but it requires extensions to be fully useful for SCADA.
Mr. Suraj Mehta submitted a seminar report on "Google App Engine" to the Department of Computer Engineering at KJ's Educational Institute in Pune, India. The report provides an overview of Google App Engine, including how it works, its storage management, development workflow, quotas and limits, and a proposed framework for using App Engine for parameter studies. It also discusses advantages, disadvantages, and compares App Engine to other cloud platforms. The seminar guide and HOD of the Computer Engineering department certified that Mehta satisfactorily completed the report as required.
Ensuring Distributed Accountability in the CloudSuraj Mehta
Ensuring distributed accountability for data sharing in the cloud is in short nothing
but a novel highly decentralized information accountability framework to keep track
of the actual usage of the users' data in the cloud. Cloud computing enables highly
ecient services that are easily consumed over the internet.
The document discusses potential solutions for integrating two different versions of Siebel. It evaluates Universal Application Network (UAN), Websphere Business Integration (WBI), Siebel Integration Layer, Siebel Master Data Applications, and a third-party custom application. Each solution is described and evaluated based on criteria like complexity, coupling, reliability, and simplicity. The document concludes that the Siebel Integration Layer provides the best solution due to its simplicity, flexibility, time to market, and reliability compared to the other options. Diagrams of sample architectures are also included in the appendix.
Smart Traffic Management System using Internet of Things (IoT)-btech-cse-04-0...TanuAgrawal27
This document presents a final year project report on developing a smart traffic management system using Internet of Things (IoT) technologies. It aims to optimize traffic light timing based on real-time vehicle counting data from road sensors. The proposed system would use sensors, microcontrollers, and cloud computing to monitor traffic flow and congestion at intersections, and dynamically adjust light durations on each lane accordingly. This is expected to reduce traffic delays and minimize commuting costs compared to traditional fixed-time traffic light systems. The report outlines the hardware, software, methodology, algorithms, and challenges of implementing such an IoT-based smart traffic management system.
Arduino bộ vi điều khiển cho tất cả chúng ta part 1tungdientu
This document provides an overview and introduction to the Arduino microcontroller platform. It discusses the Arduino Duemilanove board which uses the ATmega328 microcontroller. An example of an autonomous maze navigating robot is described to illustrate potential Arduino applications. The document also briefly discusses the open source nature of the Arduino hardware schematics and software, and some of the key hardware features of the ATmega328 microcontroller such as memory, I/O ports, and internal systems.
Review on Measurement, control and instrumentation, review in mechatronic design, mechanical, electrical and hydraulic actuator systems, electronic controllers, microprocessors, sensor communication systems, assembly language programming, and review questions in each sections
This document contains lecture notes for an Introduction to Mechatronics course. It discusses the objectives and competencies of the course, which include understanding the integration of modeling and controls in mechatronic system design. It also provides definitions and concepts of mechatronics, reviews measurement and control systems, and covers topics like actuators, sensors, communication protocols, and programming logic and controllers. The document contains several figures and tables to supplement the material.
This document provides an overview of key concepts from IEC/EN 61508, the international standard for functional safety of electrical, electronic, and programmable electronic safety-related systems. It introduces safety life cycles, risk assessment, safety integrity levels (SIL), probability of failure calculations, and different system architectures. The document contains examples to illustrate these concepts and clarify technical terms defined in the standard.
This document provides an overview and instructions for using various ControlNet communication modules with Logix5000 control systems. It describes the different module options and how to connect a computer to the ControlNet network. The document also explains how to configure ControlNet modules using RSLogix 5000 and RSNetWorx software, including adding local and remote modules, downloading projects, and scheduling the ControlNet network. Instructions are provided for controlling I/O, messaging, and communicating with HMIs over ControlNet.
This document presents a cloud decision making framework developed by Andy Marshall as part of his MSc thesis in Cloud Computing at the National College of Ireland. The framework aims to help IT decision makers in SMEs determine whether to adopt cloud computing or continue using on-premise IT solutions.
The document provides background on cloud adoption trends, benefits and challenges for SMEs. It then describes the design of the cloud decision making framework, which evaluates cloud and on-premise options across quantitative and qualitative criteria such as cost, security and vendor lock-in. The framework was implemented as a web application hosted on Microsoft Azure. It was evaluated through feedback from organizations that used the framework.
This document is a thesis submitted to the University of Economics in Prague analyzing costs of cloud IAAS for businesses. It begins with acknowledgements and a declaration by the author. The thesis will compare different cloud providers and present a framework for comparing costs of traditional on-premises IT infrastructure versus Infrastructure as a Service (IAAS) cloud solutions. It includes a theoretical background on cloud computing, case studies of small businesses, and a comparison of costs.
CHINA’S GEO-ECONOMIC OUTREACH IN CENTRAL ASIAN COUNTRIES AND FUTURE PROSPECTjpsjournal1
The rivalry between prominent international actors for dominance over Central Asia's hydrocarbon
reserves and the ancient silk trade route, along with China's diplomatic endeavours in the area, has been
referred to as the "New Great Game." This research centres on the power struggle, considering
geopolitical, geostrategic, and geoeconomic variables. Topics including trade, political hegemony, oil
politics, and conventional and nontraditional security are all explored and explained by the researcher.
Using Mackinder's Heartland, Spykman Rimland, and Hegemonic Stability theories, examines China's role
in Central Asia. This study adheres to the empirical epistemological method and has taken care of
objectivity. This study analyze primary and secondary research documents critically to elaborate role of
china’s geo economic outreach in central Asian countries and its future prospect. China is thriving in trade,
pipeline politics, and winning states, according to this study, thanks to important instruments like the
Shanghai Cooperation Organisation and the Belt and Road Economic Initiative. According to this study,
China is seeing significant success in commerce, pipeline politics, and gaining influence on other
governments. This success may be attributed to the effective utilisation of key tools such as the Shanghai
Cooperation Organisation and the Belt and Road Economic Initiative.
International Conference on NLP, Artificial Intelligence, Machine Learning an...gerogepatton
International Conference on NLP, Artificial Intelligence, Machine Learning and Applications (NLAIM 2024) offers a premier global platform for exchanging insights and findings in the theory, methodology, and applications of NLP, Artificial Intelligence, Machine Learning, and their applications. The conference seeks substantial contributions across all key domains of NLP, Artificial Intelligence, Machine Learning, and their practical applications, aiming to foster both theoretical advancements and real-world implementations. With a focus on facilitating collaboration between researchers and practitioners from academia and industry, the conference serves as a nexus for sharing the latest developments in the field.
KuberTENes Birthday Bash Guadalajara - K8sGPT first impressionsVictor Morales
K8sGPT is a tool that analyzes and diagnoses Kubernetes clusters. This presentation was used to share the requirements and dependencies to deploy K8sGPT in a local environment.
Optimizing Gradle Builds - Gradle DPE Tour Berlin 2024Sinan KOZAK
Sinan from the Delivery Hero mobile infrastructure engineering team shares a deep dive into performance acceleration with Gradle build cache optimizations. Sinan shares their journey into solving complex build-cache problems that affect Gradle builds. By understanding the challenges and solutions found in our journey, we aim to demonstrate the possibilities for faster builds. The case study reveals how overlapping outputs and cache misconfigurations led to significant increases in build times, especially as the project scaled up with numerous modules using Paparazzi tests. The journey from diagnosing to defeating cache issues offers invaluable lessons on maintaining cache integrity without sacrificing functionality.
Embedded machine learning-based road conditions and driving behavior monitoringIJECEIAES
Car accident rates have increased in recent years, resulting in losses in human lives, properties, and other financial costs. An embedded machine learning-based system is developed to address this critical issue. The system can monitor road conditions, detect driving patterns, and identify aggressive driving behaviors. The system is based on neural networks trained on a comprehensive dataset of driving events, driving styles, and road conditions. The system effectively detects potential risks and helps mitigate the frequency and impact of accidents. The primary goal is to ensure the safety of drivers and vehicles. Collecting data involved gathering information on three key road events: normal street and normal drive, speed bumps, circular yellow speed bumps, and three aggressive driving actions: sudden start, sudden stop, and sudden entry. The gathered data is processed and analyzed using a machine learning system designed for limited power and memory devices. The developed system resulted in 91.9% accuracy, 93.6% precision, and 92% recall. The achieved inference time on an Arduino Nano 33 BLE Sense with a 32-bit CPU running at 64 MHz is 34 ms and requires 2.6 kB peak RAM and 139.9 kB program flash memory, making it suitable for resource-constrained embedded systems.
TIME DIVISION MULTIPLEXING TECHNIQUE FOR COMMUNICATION SYSTEMHODECEDSIET
Time Division Multiplexing (TDM) is a method of transmitting multiple signals over a single communication channel by dividing the signal into many segments, each having a very short duration of time. These time slots are then allocated to different data streams, allowing multiple signals to share the same transmission medium efficiently. TDM is widely used in telecommunications and data communication systems.
### How TDM Works
1. **Time Slots Allocation**: The core principle of TDM is to assign distinct time slots to each signal. During each time slot, the respective signal is transmitted, and then the process repeats cyclically. For example, if there are four signals to be transmitted, the TDM cycle will divide time into four slots, each assigned to one signal.
2. **Synchronization**: Synchronization is crucial in TDM systems to ensure that the signals are correctly aligned with their respective time slots. Both the transmitter and receiver must be synchronized to avoid any overlap or loss of data. This synchronization is typically maintained by a clock signal that ensures time slots are accurately aligned.
3. **Frame Structure**: TDM data is organized into frames, where each frame consists of a set of time slots. Each frame is repeated at regular intervals, ensuring continuous transmission of data streams. The frame structure helps in managing the data streams and maintaining the synchronization between the transmitter and receiver.
4. **Multiplexer and Demultiplexer**: At the transmitting end, a multiplexer combines multiple input signals into a single composite signal by assigning each signal to a specific time slot. At the receiving end, a demultiplexer separates the composite signal back into individual signals based on their respective time slots.
### Types of TDM
1. **Synchronous TDM**: In synchronous TDM, time slots are pre-assigned to each signal, regardless of whether the signal has data to transmit or not. This can lead to inefficiencies if some time slots remain empty due to the absence of data.
2. **Asynchronous TDM (or Statistical TDM)**: Asynchronous TDM addresses the inefficiencies of synchronous TDM by allocating time slots dynamically based on the presence of data. Time slots are assigned only when there is data to transmit, which optimizes the use of the communication channel.
### Applications of TDM
- **Telecommunications**: TDM is extensively used in telecommunication systems, such as in T1 and E1 lines, where multiple telephone calls are transmitted over a single line by assigning each call to a specific time slot.
- **Digital Audio and Video Broadcasting**: TDM is used in broadcasting systems to transmit multiple audio or video streams over a single channel, ensuring efficient use of bandwidth.
- **Computer Networks**: TDM is used in network protocols and systems to manage the transmission of data from multiple sources over a single network medium.
### Advantages of TDM
- **Efficient Use of Bandwidth**: TDM all
Presentation of IEEE Slovenia CIS (Computational Intelligence Society) Chapte...University of Maribor
Slides from talk presenting:
Aleš Zamuda: Presentation of IEEE Slovenia CIS (Computational Intelligence Society) Chapter and Networking.
Presentation at IcETRAN 2024 session:
"Inter-Society Networking Panel GRSS/MTT-S/CIS
Panel Session: Promoting Connection and Cooperation"
IEEE Slovenia GRSS
IEEE Serbia and Montenegro MTT-S
IEEE Slovenia CIS
11TH INTERNATIONAL CONFERENCE ON ELECTRICAL, ELECTRONIC AND COMPUTING ENGINEERING
3-6 June 2024, Niš, Serbia
Introduction- e - waste – definition - sources of e-waste– hazardous substances in e-waste - effects of e-waste on environment and human health- need for e-waste management– e-waste handling rules - waste minimization techniques for managing e-waste – recycling of e-waste - disposal treatment methods of e- waste – mechanism of extraction of precious metal from leaching solution-global Scenario of E-waste – E-waste in India- case studies.
Using recycled concrete aggregates (RCA) for pavements is crucial to achieving sustainability. Implementing RCA for new pavement can minimize carbon footprint, conserve natural resources, reduce harmful emissions, and lower life cycle costs. Compared to natural aggregate (NA), RCA pavement has fewer comprehensive studies and sustainability assessments.
4. MILS Adaptation Engine
List of Figures
1 Adaptation Plane architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Handling of alarms and commands by the Adaptation Engine . . . . . . . . . . . . . 4
3 Initial architectural configuration of the example model . . . . . . . . . . . . . . . . 5
Page iv Version 1.0
Confidentiality: Public Distribution
28 January 2019
5. MILS Adaptation Engine
Document Control
Version Status Date
0.1 Document outline 11 January 2019
0.4 Initial content 17 January 2019
0.8 Full content 25 January 2019
1.0 Final version 28 January 2019
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page v
6. MILS Adaptation Engine
1 Overview
In this training submodule we outline the core workings of the MILS Adaptation System (for details
please refer to the project deliverable D4.3 [1]) and we describe how to create the artifacts which are
taken as input by the MILS Adaptation System. Specifically, we focus on the Adaptation Engine, the
core component of the MILS Adaptation System.
The training submodule CITADEL Context Awareness describes the Context Awareness subcompo-
nent of the MILS Adaptation System, and the training module CITADEL Platform: Model-based
Adaptation describes how to start the MILS Adaptation System.
Following this document requires:
• a text editor, and
• the COMPASS 3 release for CITADEL.
2 Adaptation Engine overview
The MILS Adaptation system is implemented as a set of components, which together constitute
the Adaptation Plane. The main functionality of the Adaptation Plane (Fig. 1) is to take as input
alarms from the Monitoring Plane, compute the model of the next architectural configuration and
send it to the Configuration Plane. In addition, it sends status notifications to the operator console
from which it can also receive commands, and it sends the next architectural configuration to the
Certification Assurance Plane, requesting the assurance case update for the next configuration. An
optional Context Awareness component can be used in order to estimate the current execution context,
which is an additional source of information for an operator monitoring the system operation.
Adaptation Engine is the central component of the Adaptation Plane, implementing a rule-based
adaptation strategy. Evaluator Module is a helper component whose purpose is to perform model-
based reasoning in order to find the next configuration. In the following, we describe the interfaces
and the functionality of the Adaptation Engine.
2.1 Interfaces
The interfaces of the Adaptation Engine are as follows.
2.1.1 Interface with the Monitoring Plane
Adaptation Engine receives alarms from the Monitoring Plane. The alarms are specified in the system
model; at runtime this interface is fully automatic and allows no human interaction.
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 1
7. MILS Adaptation Engine
Monitoring
Plane
Configuration
Plane
MILS Console
Subsystem
Adaptation
Engine
Evaluator
Module
Adaptation Plane
alarms
commands
system
status
evaluation
requests
model of next
architectural
configuration
model of next
architectural
configuration
reconfiguration
status
Certification
Assurance Plane
Context
Awareness
current context
monitored data
context feedback
Figure 1: Adaptation Plane architecture
2.1.2 Interface with the MILS Console Subsystem
Adaptation Engine sends notifications about all events to the MILS Console Subsystem.
Adaptation Engine may receive commands from the MILS Console Subsystem. A command may be
either a reconfiguration request or a request to stop execution.
Reconfiguration request A reconfiguration request is a triplet containing the following comma-
separated elements:
• a requested reconfiguration action,
• a priority,
• a time limit,
where the priority and time limit are optional and can be omitted. The syntax and semantics of the
above three elements are described in Section 4. The reconfiguration request may be used by an
operator in order to manually bring the system to a desired architectural configuration.
Request to stop execution An operator can request immediate stopping of execution of the Adap-
tation Engine by sending it the command halt.
Page 2 Version 1.0
Confidentiality: Public Distribution
28 January 2019
8. MILS Adaptation Engine
2.1.3 Interface with the Configuration Plane
In order to request a reconfiguration, the Adaptation Engine sends to the Configuration Plane the syn-
thesized model of the next configuration of the system. The Configuration Plane responds by sending
the status (success or failure) of the attempted reconfiguration. This interface is fully automatic and
allows no human interaction.
2.1.4 Interface with the Certification Assurance Plane
The Adaptation Engine sends to the Certification Assurance Plane a model of the next architectural
configuration, in order to request an update of the assurance case. This interface is fully automatic
and allows no human interaction.
2.1.5 Interface with the Evaluator Module
In order to request the computation of the next architectural configuration, the Adaptation Engine
sends to the Evaluator Module a representation of the current architectural configuration in the form
of an assignment of values to parameters (see next subsection), a requested reconfiguration action,
and a time limit.
The Evaluator Module responds within the specified time limit by either sending an instantiated
model of the next configuration, or by sending a notification about the failure to compute the next
architectural configuration.
This interface is fully automatic and allows no human interaction.
2.2 Functionality
On startup, the Adaptation Engine loads the following artifacts:
• an initial architectural configuration of the system, specified by the initial assignment to the
parameters,
• a rule table which specifies the reconfiguration strategy that is to be implemented by the Adap-
tation Plane.
The Adaptation Engine is a simple state machine. Its state contains the current assignment to the
system parameters (which defines the current architectural configuration of the system) and other
elements such as the alarm and rule which are currently being processed, as well as the information
used for managing communication with the other components of the CITADEL Framework (such as
flags to denote whether currently there is ongoing computation by the Evaluator Module or reconfig-
uration by the Configuration Plane).
The main functionality of the Adaptation Engine is to listen for alarms incoming from the Monitoring
Plane, match received alarm with an entry in its rule table in order to trigger the appropriate recon-
figuration action, request (based on the selected action) from the Evaluator Module synthesis of the
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 3
9. MILS Adaptation Engine
model of the next architectural configuration, request (based on the synthesized model) from the Con-
figuration Plane the reconfiguration of the system, and request re-certification from the Certification
Assurance Plane.
In addition, the Adaptation Engine may receive reconfiguration commands from the operator via the
MILS Console System, which are handled analogously to the reconfiguration actions triggered by
the alarms.
Figure 2: Handling of alarms and commands by the Adaptation Engine
Figure 2 shows the algorithm used by the Adaptation Engine to handle incoming alarms and operator
commands. When an alarm is received by the Adaptation Engine, it is matched against the rules
in the rule table. If there is a matching rule, and its specified priority is higher than the currently
evaluating action, the rule is triggered and the reconfiguration action specified in the rule is evaluated.
Evaluation of the action involves requesting the evaluation from the Evaluator Module, which returns
(within the time limit specified in the rule) either a model of the next configuration of the system or
a failure status. If the evaluation succeeds, the Adaptation Engine requests the reconfiguration and
re-certification of the system, from the Configuration Plane and the Certification Assurance Plane,
respectively. In case the evaluation fails, its fallback rule (if any) is triggered. (Another possibility,
not shown in the figure, is that the evaluation may be cancelled if a higher priority rule is triggered
by another alarm or if a higher priority operator command is received concurrently with the current
evaluation.) In case of reconfiguration failure by the Configuration Plane, the Adaptation Engine
halts, stopping the MILS Adaptation System (reconfiguration failures are considered fatal because
they may leave the system in an inconsistent configuration). Commands received from the operator
are handled in the same manner, except that the priority, action and timeout are obtained from the
Page 4 Version 1.0
Confidentiality: Public Distribution
28 January 2019
10. MILS Adaptation Engine
command itself and not from a matching rule as in the case of an alarm. Another difference is that
for operator commands there are no fallback rules.
More information about the Adaptation Engine can be found in the project deliverable D4.3 [1].
3 Specifying the initial architectural configuration
In this section we specify an initial assignment of values to the system parameters. As the exam-
ple model, we use the load balancer model developed in the training module CITADEL Modeling,
Specification and Verification Tools, and whose listing can be found in Appendix A.1.
The initial assignment of values to the parameters, which specifies the initial architectural configu-
ration of the system, is a formula specifying the values of all parameters. The following is an initial
assignment for the running example, which specifies the configuration shown in Figure 3:
node_ids = {0, 1} and db_node_id = 0 and
user_ids = {0, 1, 2} and server_block_ids = {0, 1} and
server_block_redundant[0] = false and server_block_redundant[1] = true
Figure 3: Initial architectural configuration of the example model
In order to check that the specified initial architectural configuration corresponds to the intended one,
the tool instantiate.py can be used to instantiate the configuration from the system model and
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 5
11. MILS Adaptation Engine
a file containing the initial assignment to parameters. If these two artifacts are stored in the files
model.slim and assignment.txt, respectively, the model of the architectural configuration
corresponding to the assignment can be generated by invoking the tool instantiate.py:
compass3$ python scripts/instantiate.py model.slim
--assign assignment.txt
--- Instance of model.slim
[rest of output omitted]
Appendix A.3 contains the instantiated model of the initial architectural configuration of the example
model, obtained by invoking:
compass3$ python scripts/instantiate.py
/path/to/load_balancer_with_monitors.slim --assign
/path/to/load_balancer_with_monitors_assignment.txt
[output omitted]
For a video demonstration of the use of this tool, please refer to the training module CITADEL
Modeling, Specification and Verification Tools.
4 Specifying adaptation rule table
The adaptation rule table specifies the reconfiguration strategy implemented by the Adaptation En-
gine.
4.1 Rule table semantics
The rule table contains a sequence of rules, specified in the rows of the rule table. A rule which
specifies an alarm pattern can be triggered by an incoming alarm with the matching name, while a
rule which does not specify an alarm pattern is a fallback rule, and is automatically triggered when
the execution of the rule in the preceding row of the table fails. This results in the following simple
semantics: when an alarm is received, the matching rule in the rule table is triggered and its action is
evaluated. If the evaluation fails, the fallback rule (if any), specified in the next row of the rule table,
is triggered, evaluating its action. This process of falling down through the fallback rules in the rule
table is repeated until evaluation of some rule succeeds or there are no more fallback rules.
4.2 Reconfiguration rules
Each rule in the rule table contains five elements:
• a unique rule identifier (for example r2);
• (optional) an alarm pattern, consisting of the alarm name and identifiers to which the alarm
values are bound when the alarm is received (for example malicious_user(id)); rule
without an alarm pattern is a fallback rule (as explained above);
Page 6 Version 1.0
Confidentiality: Public Distribution
28 January 2019
12. MILS Adaptation Engine
• the reconfiguration action (for example remove_user[id]);
• (optional) an integer value specifying the rule priority (for example 0); default priority (if
omitted) is 0;
• (optional) a floating point value specifying the evaluation time limit in seconds (for example
60.0).
4.2.1 Alarms and alarm patterns
Alarms An alarm
alarm_name(val_1, ..., val_n)
received from the Monitoring Plane contains
• an alarm name alarm_name,
• a (possibly empty) list of alarm values val_1, ..., val_n.
The alarm name is an identifier, while the values can be identifiers, Booleans, integers or reals. An
example alarm is
malicious_user(7)
where the alarm name is malicious_user and there is one alarm value 7.
Alarm patterns An alarm pattern
alarm_pattern_name(arg_1, ..., arg_m)
specified in a rule contains
• an alarm pattern name alarm_pattern_name,
• a (possibly empty) list of arguments arg_1, ..., arg_m.
The alarm pattern name and its arguments are identifiers. An example alarm pattern is
malicious_user(user_id)
where the alarm pattern name is malicious_user and there is one argument user_id.
Matching of alarms and alarm patterns An alarm and an alarm pattern match if their names are
the same,
alarm_name = alarm_pattern_name
and if the number of their values and arguments is the same,
n = m .
Matching binds the names of the alarm pattern arguments to the corresponding alarm values. For
example, the above example alarm and alarm pattern match, resulting in the binding user_id → 7.
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 7
13. MILS Adaptation Engine
4.2.2 Reconfiguration actions
The reconfiguration action can be one of:
• a reconfiguration transition label, as specified in the system model with specified transition
arguments (for example, add_user[11]) or unspecified transition arguments (for example,
add_user[*]);
• one of the special reconfiguration actions
• search "<property>", specifying that the reasoning-based adaptation should be
performed: the MILS Adaptation System in this case automatically selects a reconfigura-
tion transition which leads to a configuration satisfying the optional specified property,
• ask, specifying that an engineer should be asked to provide the (values of parameters for
the) next architectural configuration,
• halt, specifying that the MILS Adaptation System should immediately halt.
Action halt is handled directly by the Adaptation Engine, while the rest are first evaluated by the
Evaluator Module as described previously.
4.3 Specifying the rule table
The file containing the rule table is a plain text file with one rule per line. The five elements in a rule
are separated by semicolons:
rule_id_1 ; alarm_pattern_1 ; reconf_action_1 ; priority_1 ; time_limit_1
rule_id_2 ; alarm_pattern_2 ; reconf_action_2 ; priority_2 ; time_limit_2
...
rule_id_n ; alarm_pattern_n ; reconf_action_n ; priority_n ; time_limit_n
In the following, we specify the rules for the example load balancer model (see Appendix A.1 and the
training module CITADEL Modeling, Specification and Verification Tools). The first rule implements
addition of a user when the alarm new_user() is received. The used action is add_user[*],
specifying addition to the system of a user with an unspecified index (the appropriate index will be
selected automatically by the Evaluator Module). The priority is set to 0, and the time limit is set to
0:
r1 ; new_user() ; add_user[*] ; 0 ; 0
The second rule implements removal of a user when its monitor detects malicious behaviour. Here
the value from the alarm (bound to identifier id when the alarm pattern in the rule is matched with
the alarm) is passed as the first argument to the reconfiguration action remove_user[id]:
r2 ; malicious_user(id) ; remove_user[id] ; 0 ; 0
The third and the fourth rule implement addition of a server block (with a redundant application
server) when server overload is detected: the third rule tries to apply the reconfiguration transition
add_server_block[*][true] and, if it fails, the fourth rule is executed, asking the engineer
to provide the next architectural configuration within 5 minutes (300 seconds). The priority of the
fallback rule is higher than that of the previous rule to reflect the increased criticality.
Page 8 Version 1.0
Confidentiality: Public Distribution
28 January 2019
14. MILS Adaptation Engine
r3 ; overload(load) ; add_server_block[*][true] ; 0 ; 0
r4 ; ; ask ; 1 ; 300
The next three rules implement replacement of a server block when one of the servers in it fails. If
the server block replacement specified in rule r5 fails, the engineer is asked by rule r6 to provide
the next architectural reconfiguration. If he is unable to do so, the next fallback rule r7 is executed
and the Adaptation System halts.
r5 ; server_failed(kind, id) ; replace_server_block[id][*] ; 0 ; 0
r6 ; ; ask ; 1 ;
r7 ; ; halt ; 2 ;
The last two rules implement migration of the database to the other node when the alarm
node_unhealthy() is received. If the migration fails, the Adaptation System halts.
r8 ; node_unhealthy() ; migrate_database ; 0 ; 0
r9 ; ; halt ; 1 ;
The complete rule table, with all of the above rules, can be found in Appendix A.4.
An explanation and a video demonstration of the use of the rule table and the initial assignment in
the start-up of the Adaptation Plane can be found in the training module CITADEL Platform: Model-
Based Adaptation.
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 9
15. MILS Adaptation Engine
References
[1] MILS Adaptation System. Technical Report D4.3, Version 1.0, CITADEL Project, May 2018. 1,
5
Page 10 Version 1.0
Confidentiality: Public Distribution
28 January 2019
16. MILS Adaptation Engine
A Example artifacts
A.1 Load Balancer Model
Content of the system model file load_balancer_with_monitors.slim:
package LoadBalancerModel
public
--- Abstract data types ---
data HTTP_Message
end HTTP_Message;
data implementation HTTP_Message.Data
end HTTP_Message.Data;
data SQL_Query
end SQL_Query;
data implementation SQL_Query.Data
end SQL_Query.Data;
--- Subject representing a user ---
subject User
features
get: out event data port HTTP_Message.Data;
end User;
subject implementation User.Imp
end User.Imp;
--- Subject representing a web server ---
subject WebServer
features
in_get: in event data port HTTP_Message.Data;
out_get: out event data port HTTP_Message.Data;
heartbeat: out event port;
end WebServer;
subject implementation WebServer.Imp
end WebServer.Imp;
--- Subject representing an application server ---
subject ApplicationServer
features
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 11
17. MILS Adaptation Engine
in_get: in event data port HTTP_Message.Data;
out_get: out event data port SQL_Query.Data;
heartbeat: out event port;
end ApplicationServer;
subject implementation ApplicationServer.Imp
end ApplicationServer.Imp;
--- Subject representing a database ---
subject Database
parameters
port_ids: set of index;
features
get1: set indexed by port_ids of in event data port SQL_Query;
get2: set indexed by port_ids of in event data port SQL_Query;
end Database;
subject implementation Database.Imp
end Database.Imp;
--- Subject representing a load balancer ---
subject LoadBalancer
parameters
port_ids: set of index;
features
in_get: in event data port HTTP_Message.Data;
out_get: set indexed by port_ids
of out event data port HTTP_Message.Data;
avg_load: out event data port real;
end LoadBalancer;
subject implementation LoadBalancer.Imp
end LoadBalancer.Imp;
--- System representing a load balancer monitor ---
system LoadMonitor
features
load_in: in event data port real;
overload: out event data port real {
Alarm => true;
AlarmArguments => "load_in";
MonitoringProperty =>
"always (last_data(load_in) < MaxLoad)";
};
Page 12 Version 1.0
Confidentiality: Public Distribution
28 January 2019
18. MILS Adaptation Engine
properties
FDIR => true;
end LoadMonitor;
system implementation LoadMonitor.Imp
end LoadMonitor.Imp;
--- Datatype for the alarm subject_failed ---
data ServerFailed
end ServerFailed;
data implementation ServerFailed.Data
subcomponents
sk: data enum(web_server, main_app_server,
redundant_app_server);
bi: data index;
end ServerFailed.Data;
--- System representing a heartbeat monitor ---
system HeartbeatMonitor
parameters
server_kind: enum(web_server, main_app_server,
redundant_app_server);
block_id: index;
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(server_kind, block_id)";
MonitoringProperty =>
"always (time_until(heartbeat_in) msec < HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor;
system implementation HeartbeatMonitor.Imp
end HeartbeatMonitor.Imp;
--- Parametrized architecture representing a server block ---
system ServerBlock
parameters
id: index;
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 13
19. MILS Adaptation Engine
redundantAS: bool;
features
in_get: in event data port HTTP_Message.Data;
out_get1: out event data port SQL_Query.Data;
out_get2: out event data port SQL_Query.Data if redundantAS;
end ServerBlock;
system implementation ServerBlock.Imp
subcomponents
WS: subject WebServer.Imp;
WS_mon: system HeartbeatMonitor.Imp
where WS_mon.server_kind = web_server
and WS_mon.block_id = id;
AS1: subject ApplicationServer.Imp;
AS1_mon: system HeartbeatMonitor.Imp
where AS1_mon.server_kind = main_app_server
and AS1_mon.block_id = id;
AS2: subject ApplicationServer.Imp if redundantAS;
AS2_mon: system HeartbeatMonitor.Imp
where AS2_mon.server_kind = redundant_app_server
and AS2_mon.block_id = id
if redundantAS;
connections
port in_get -> WS.in_get;
port WS.out_get -> AS1.in_get;
port WS.out_get -> AS2.in_get if redundantAS;
port WS.heartbeat -> WS_mon.heartbeat_in;
port AS1.out_get -> out_get1;
port AS1.heartbeat -> AS1_mon.heartbeat_in;
port AS2.out_get -> out_get2 if redundantAS;
port AS2.heartbeat -> AS2_mon.heartbeat_in if redundantAS;
end ServerBlock.Imp;
--- System representing a user anomaly monitor ---
system UserMonitor
parameters
user_id: index;
features
user_out: in event data port HTTP_Message.Data;
malicious_user: out event data port index {
Alarm => true;
AlarmArguments => "user_id";
MonitoringProperty => "never Malicious(last_data(user_out))";
};
properties
FDIR => true;
Page 14 Version 1.0
Confidentiality: Public Distribution
28 January 2019
20. MILS Adaptation Engine
end UserMonitor;
system implementation UserMonitor.Imp
end UserMonitor.Imp;
--- System representing a monitor for incoming users ---
system IncomingMonitor
features
new_user: out event port {
Alarm => true;
};
properties
FDIR => true;
end IncomingMonitor;
system implementation IncomingMonitor.Imp
end IncomingMonitor.Imp;
--- Node representing a hardware node ---
node Node
features
healthy: out event data port bool;
end Node;
node implementation Node.Imp
end Node.Imp;
--- System representing a hardware node monitor ---
system NodeMonitor
features
healthy_in: in event data port bool;
node_unhealthy: out event port {
Alarm => true;
MonitoringProperty =>
"always (last_data(healthy_in) = true)";
};
properties
FDIR => true;
end NodeMonitor;
system implementation NodeMonitor.Imp
end NodeMonitor.Imp;
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 15
21. MILS Adaptation Engine
--- Parametrized architecture representing the system ---
system System
parameters
user_ids: set of index;
server_block_ids: set of index;
server_block_redundant: set indexed by server_block_ids of bool;
node_ids: set of index;
db_node_id: index;
assumptions
size(server_block_ids) > 0;
db_node_id in node_ids;
end System;
system implementation System.Imp
subcomponents
users: set indexed by user_ids of subject User.Imp;
incoming_mon: system IncomingMonitor.Imp;
user_mons: set indexed by user_ids of system UserMonitor.Imp
where forall(i in user_ids, user_mons[i].user_id = i);
load_balancer: subject LoadBalancer.Imp
where load_balancer.port_ids = server_block_ids;
load_balancer_mon: system LoadMonitor.Imp;
server_blocks: set indexed by server_block_ids
of system ServerBlock.Imp
where forall(i in server_block_ids,
server_blocks[i].id = i and
server_blocks[i].redundantAS
= server_block_redundant[i]);
database: subject Database.Imp
{ DeployedOn => reference(nodes[db_node_id]); }
where database.port_ids = server_block_ids;
nodes: set indexed by node_ids of node Node.Imp;
db_node_mon: system NodeMonitor.Imp;
connections
port users[i].get -> load_balancer.in_get for i in user_ids;
port users[i].get -> user_mons[i].user_out for i in user_ids;
port load_balancer.out_get[i] -> server_blocks[i].in_get
for i in server_block_ids;
port load_balancer.avg_load -> load_balancer_mon.load_in;
port server_blocks[i].out_get1 -> database.get1[i]
for i in server_block_ids;
port server_blocks[i].out_get2 -> database.get2[i]
if server_block_redundant[i]
for i in server_block_ids;
port nodes[db_node_id].healthy -> db_node_mon.healthy_in;
end System.Imp;
Page 16 Version 1.0
Confidentiality: Public Distribution
28 January 2019
22. MILS Adaptation Engine
--- Configuration transition system ---
CTS SystemCTS
architecture
a: System.Imp where a.node_ids = {0, 1} and
size(a.user_ids) <= 100 and
size(a.server_block_ids) <= 10;
initial
a.user_ids = {0, 1, 2} and a.server_block_ids = {0, 1}
and a.server_block_redundant[0] = false
and a.server_block_redundant[1] = true
and a.node_ids = {0, 1} and a.db_node_id = 0;
transitions
add_user[id]: step(next(a.user_ids) = add(a.user_ids, {id}))
for id not in a.user_ids;
remove_user[id]: step(next(a.user_ids) =
remove(a.user_ids, {id}))
for id in a.user_ids;
add_server_block[id][red]:
step(next(a.server_block_ids) = add(a.server_block_ids, {id})
and next(a.server_block_redundant[id]) = red)
for id not in a.server_block_ids, red in bool;
remove_server_block[id]:
step(next(a.server_block_ids) =
remove(a.server_block_ids, {id}))
for id in a.server_block_ids;
replace_server_block[old_id][new_id]:
step(next(a.server_block_ids) =
add(remove(a.server_block_ids, {old_id}), {new_id})
and next(a.server_block_redundant[new_id]) =
a.server_block_redundant[old_id])
for old_id in a.server_block_ids,
new_id not in a.server_block_ids;
flip_redundancy[id]:
step(next(a.server_block_redundant[id]) =
not a.server_block_redundant[id])
for id in a.server_block_ids;
migrate_database:
step(next(a.db_node_id) = case a.db_node_id = 0 : 1
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 17
23. MILS Adaptation Engine
otherwise 0 end);
end SystemCTS;
properties
Constants => "Malicious: function HTTP_Message.Data -> bool;
HeartbeatTimeout: clock msec := 1 msec;
MaxLoad: real := 0.9;";
end LoadBalancerModel;
A.2 Initial assignment file
Content of the assignment file load_balancer_with_monitors_assignment.txt:
node_ids = {0, 1} and db_node_id = 0 and
user_ids = {0, 1, 2} and server_block_ids = {0, 1} and
server_block_redundant[0] = false and server_block_redundant[1] = true
A.3 Initial instance
Content of the model file load_balancer_with_monitors_instance.slim:
--- Instance of load_balancer_with_monitors.slim
--- Root implementation: LoadBalancerModel::System.Imp
--- Assignment: user_ids = {2, 0, 1} and server_block_ids = {0, 1} and
--- server_block_redundant[0] = false and
--- server_block_redundant[1] = true and
--- node_ids = {0, 1} and db_node_id = 0
package LoadBalancerModel
public
node Node
features
healthy: out event data port bool;
end Node;
subject ApplicationServer
features
heartbeat: out event port;
in_get: in event data port HTTP_Message.Data;
out_get: out event data port SQL_Query.Data;
end ApplicationServer;
subject Database__0
features
Page 18 Version 1.0
Confidentiality: Public Distribution
28 January 2019
24. MILS Adaptation Engine
get1__0: in event data port SQL_Query;
get1__1: in event data port SQL_Query;
get2__0: in event data port SQL_Query;
get2__1: in event data port SQL_Query;
end Database__0;
subject LoadBalancer__0
features
avg_load: out event data port real;
in_get: in event data port HTTP_Message.Data;
out_get__0: out event data port HTTP_Message.Data;
out_get__1: out event data port HTTP_Message.Data;
end LoadBalancer__0;
subject User
features
get: out event data port HTTP_Message.Data;
end User;
subject WebServer
features
heartbeat: out event port;
in_get: in event data port HTTP_Message.Data;
out_get: out event data port HTTP_Message.Data;
end WebServer;
system HeartbeatMonitor__0
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(main_app_server, 0)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__0;
system HeartbeatMonitor__1
features
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 19
25. MILS Adaptation Engine
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(web_server, 0)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__1;
system HeartbeatMonitor__2
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(main_app_server, 1)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__2;
system HeartbeatMonitor__3
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(web_server, 1)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__3;
system HeartbeatMonitor__4
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Page 20 Version 1.0
Confidentiality: Public Distribution
28 January 2019
26. MILS Adaptation Engine
Alarm => true;
AlarmArguments => "(redundant_app_server, 1)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__4;
system IncomingMonitor
features
new_user: out event port { Alarm => true; };
properties
FDIR => true;
end IncomingMonitor;
system LoadMonitor
features
load_in: in event data port real;
overload: out event data port real {
Alarm => true;
AlarmArguments => "load_in";
MonitoringProperty =>
"always (last_data(load_in) < MaxLoad)";
};
properties
FDIR => true;
end LoadMonitor;
system NodeMonitor
features
healthy_in: in event data port bool;
node_unhealthy: out event port {
Alarm => true;
MonitoringProperty =>
"always (last_data(healthy_in) = true)";
};
properties
FDIR => true;
end NodeMonitor;
system ServerBlock__0
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 21
27. MILS Adaptation Engine
features
in_get: in event data port HTTP_Message.Data;
out_get1: out event data port SQL_Query.Data;
end ServerBlock__0;
system ServerBlock__1
features
in_get: in event data port HTTP_Message.Data;
out_get1: out event data port SQL_Query.Data;
out_get2: out event data port SQL_Query.Data;
end ServerBlock__1;
system System__0
end System__0;
system UserMonitor__0
features
malicious_user: out event data port int {
Alarm => true;
AlarmArguments => "0";
MonitoringProperty =>
"never (Malicious(last_data(user_out)))";
};
user_out: in event data port HTTP_Message.Data;
properties
FDIR => true;
end UserMonitor__0;
system UserMonitor__1
features
malicious_user: out event data port int {
Alarm => true;
AlarmArguments => "1";
MonitoringProperty =>
"never (Malicious(last_data(user_out)))";
};
user_out: in event data port HTTP_Message.Data;
properties
FDIR => true;
end UserMonitor__1;
system UserMonitor__2
features
Page 22 Version 1.0
Confidentiality: Public Distribution
28 January 2019
28. MILS Adaptation Engine
malicious_user: out event data port int {
Alarm => true;
AlarmArguments => "2";
MonitoringProperty =>
"never (Malicious(last_data(user_out)))";
};
user_out: in event data port HTTP_Message.Data;
properties
FDIR => true;
end UserMonitor__2;
node implementation Node.Imp__0
end Node.Imp__0;
subject implementation ApplicationServer.Imp__0
end ApplicationServer.Imp__0;
subject implementation Database__0.Imp__0
end Database__0.Imp__0;
subject implementation LoadBalancer__0.Imp__0
end LoadBalancer__0.Imp__0;
subject implementation User.Imp__0
end User.Imp__0;
subject implementation WebServer.Imp__0
end WebServer.Imp__0;
system implementation HeartbeatMonitor__0.Imp__0
end HeartbeatMonitor__0.Imp__0;
system implementation HeartbeatMonitor__1.Imp__0
end HeartbeatMonitor__1.Imp__0;
system implementation HeartbeatMonitor__2.Imp__0
end HeartbeatMonitor__2.Imp__0;
system implementation HeartbeatMonitor__3.Imp__0
end HeartbeatMonitor__3.Imp__0;
system implementation HeartbeatMonitor__4.Imp__0
end HeartbeatMonitor__4.Imp__0;
system implementation IncomingMonitor.Imp__0
end IncomingMonitor.Imp__0;
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 23
29. MILS Adaptation Engine
system implementation LoadMonitor.Imp__0
end LoadMonitor.Imp__0;
system implementation NodeMonitor.Imp__0
end NodeMonitor.Imp__0;
system implementation ServerBlock__0.Imp__0
subcomponents
AS1: subject ApplicationServer.Imp__0;
AS1_mon: system HeartbeatMonitor__0.Imp__0;
WS: subject WebServer.Imp__0;
WS_mon: system HeartbeatMonitor__1.Imp__0;
connections
port AS1.heartbeat -> AS1_mon.heartbeat_in;
port AS1.out_get -> out_get1;
port WS.heartbeat -> WS_mon.heartbeat_in;
port WS.out_get -> AS1.in_get;
port in_get -> WS.in_get;
end ServerBlock__0.Imp__0;
system implementation ServerBlock__1.Imp__0
subcomponents
AS1: subject ApplicationServer.Imp__0;
AS1_mon: system HeartbeatMonitor__2.Imp__0;
AS2: subject ApplicationServer.Imp__0;
AS2_mon: system HeartbeatMonitor__4.Imp__0;
WS: subject WebServer.Imp__0;
WS_mon: system HeartbeatMonitor__3.Imp__0;
connections
port AS1.heartbeat -> AS1_mon.heartbeat_in;
port AS1.out_get -> out_get1;
port AS2.heartbeat -> AS2_mon.heartbeat_in;
port AS2.out_get -> out_get2;
port WS.heartbeat -> WS_mon.heartbeat_in;
port WS.out_get -> AS1.in_get;
port WS.out_get -> AS2.in_get;
port in_get -> WS.in_get;
end ServerBlock__1.Imp__0;
system implementation System__0.Imp__0
subcomponents
database: subject Database__0.Imp__0
Page 24 Version 1.0
Confidentiality: Public Distribution
28 January 2019
30. MILS Adaptation Engine
{ DeployedOn => reference(nodes__0); };
db_node_mon: system NodeMonitor.Imp__0;
incoming_mon: system IncomingMonitor.Imp__0;
load_balancer: subject LoadBalancer__0.Imp__0;
load_balancer_mon: system LoadMonitor.Imp__0;
nodes__0: node Node.Imp__0;
nodes__1: node Node.Imp__0;
server_blocks__0: system ServerBlock__0.Imp__0;
server_blocks__1: system ServerBlock__1.Imp__0;
user_mons__0: system UserMonitor__0.Imp__0;
user_mons__1: system UserMonitor__1.Imp__0;
user_mons__2: system UserMonitor__2.Imp__0;
users__0: subject User.Imp__0;
users__1: subject User.Imp__0;
users__2: subject User.Imp__0;
connections
port load_balancer.avg_load -> load_balancer_mon.load_in;
port load_balancer.out_get__0 -> server_blocks__0.in_get;
port load_balancer.out_get__1 -> server_blocks__1.in_get;
port nodes__0.healthy -> db_node_mon.healthy_in;
port server_blocks__0.out_get1 -> database.get1__0;
port server_blocks__1.out_get1 -> database.get1__1;
port server_blocks__1.out_get2 -> database.get2__1;
port users__0.get -> load_balancer.in_get;
port users__0.get -> user_mons__0.user_out;
port users__1.get -> load_balancer.in_get;
port users__1.get -> user_mons__1.user_out;
port users__2.get -> load_balancer.in_get;
port users__2.get -> user_mons__2.user_out;
end System__0.Imp__0;
system implementation UserMonitor__0.Imp__0
end UserMonitor__0.Imp__0;
system implementation UserMonitor__1.Imp__0
end UserMonitor__1.Imp__0;
system implementation UserMonitor__2.Imp__0
end UserMonitor__2.Imp__0;
data HTTP_Message
end HTTP_Message;
data SQL_Query
end SQL_Query;
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 25
31. MILS Adaptation Engine
data ServerFailed
end ServerFailed;
data implementation HTTP_Message.Data
end HTTP_Message.Data;
data implementation SQL_Query.Data
end SQL_Query.Data;
data implementation ServerFailed.Data
subcomponents
sk: data enum(web_server, main_app_server,
redundant_app_server);
bi: data int;
end ServerFailed.Data;
properties
Constants => "Malicious: function HTTP_Message.Data -> bool;
HeartbeatTimeout: clock msec := 1 msec;
MaxLoad: real := 0.9;";
end LoadBalancerModel;
A.4 Rule table
Content of the rule table file load_balancer_with_monitors_rules.csv:
r1 ; new_user() ; add_user[*] ; 0 ; 0
r2 ; malicious_user(id) ; remove_user[id] ; 0 ; 0
r3 ; overload(load) ; add_server_block[*][true] ; 0 ; 0
r4 ; ; ask ; 1 ; 300
r5 ; server_failed(kind, id) ; replace_server_block[id][*] ; 0 ; 0
r6 ; ; ask ; 1 ;
r7 ; ; halt ; 2 ;
r8 ; node_unhealthy() ; migrate_database ; 0 ; 0
r9 ; ; halt ; 1 ;
Page 26 Version 1.0
Confidentiality: Public Distribution
28 January 2019