<commit_before>[![Build Status](https://travis-ci.org/visor-vu/chariot.svg?branch=master)](https://travis-ci.org/visor-vu/chariot)

# CHARIOT

## Summary
CHARIOT is a holistic solution that facilitates design, development, and management of distributed systems. Although the current implementation of CHARIOT was designed and tested with use-case scenarios specific to the domain of [extensible Cyber-Physical Systems(CPS)](http://etd.library.vbe.proxy.library.vanderbilt.edu/available/etd-11172016-154749/unrestricted/Pradhan.pdf), the underlying concepts are applicable to distributed systems in general. Following are the key aspects of CHARIOT:
* Design-time, generic system description using follwoing abstract concepts: 
   * The goal/mission of a system and ojectives required to achieve a system's goal
   * Functionalities that are required to satisfy an objective and dependencies between them
   * Replication constraints associated with different functionalities (mainly for redundancy)
   * Component types that provide functionalities (not explicit component instances)
   * Hardware categories and templates (not explicit hardware resources)
* At runtime, depending on the required functionalities and a set of component types, a set component instances and their inter-dependency is computed (this is the software graph)
* Different hardware resources (nodes that can be equipped with various devices) can ingress of egress a cluster dynamically at runtime; as such, at any given time there is a set of available harware resources with links between them (this is the hardware graph)
* The management problem being solved by CHARIOT is that of mapping the software graph onto the hardware graph while satisfying different system constraints

### Vision: Managing extensible CPS at Scale
Cyber-Physical Systems (CPS) have traditionally been designed as closed systems for specific domains. This design philosophy was necessitated by the stringent requirements on system correctness, reliability, security and privacy. However, with increasing push towards open architectures and the emphasis on integration of CPS with Internet of Things (IoT), cloud computing, and online data analytics, as evidenced by the increasing interest in Smart City cyber-physical applications, the trend in CPS design and deployment is transitioning towards a more open and dynamic approach. This results in extensible CPS that are not built as a single function system, but rather as loosely connected, networked platforms comprising subsystems pertaining to different domains. These heterogeneous cyber-physical platforms simultaneously host multi-domain cyber-physical applications and their behavior cannot be encoded a priori, but it evolves over time depending on the hosted applications.

The figure below presents a target system architecture for CHARIOT. Edge nodes are resource constrained nodes that are equipped with various sensors and/ or actuators, and deployed in the physical environment. Management and monitoring infrastructures can be run on these nodes as long running platform services. Applications make use of available resources for sensing, actuating, and non-resource intensive computations. Different middleware solutions can be used by these applications to communicate with each other.

<img src="https://github.com/visor-vu/chariot/blob/master/Figures/TargetArchitecture.png" width="75%" height="60%"/>

All computation cannot be run on edge nodes; edge nodes should run small computations that require real-time response. As such extensible CPS requires us to view CPS challenges from a collaborative perspective, where it is critical to utilize advancement in other computing paradigm such as cloud computing to realize a complex computing paradigm. Resource intensive computations that are not associated with real-time requirement can be deployed on a cloud. This yields a multi-layer architecture whereby application properties and requirements determine associated computation proximity and where they can be deployed.

## Architectural Overview
CHARIOT consists of different entities that can be classified into three layers:

1. **Design layer**: This is the top-most layer and comprises a novel DSML (Domain Specific Modeling Language). This DSML is called CHARIOT-ML and it is built using the [Xtext framework](http://www.eclipse.org/Xtext/). CHARIOT-ML consists of (1) language grammars that are metamodels, and (2) interpreters that traverses user models to retrieve design-time system description.

2. **Data layer**: This is the middle layer. It comprises a well-defined data model that codifies the format in which system information (design-time system descriptions and runtime system representation) must be stored. CHARIOT currently uses [MongoDB](https://www.mongodb.com/) to store system information. This layer helps decouple the design layer (top) from the management layer (bottom).

  <img src="https://github.com/visor-vu/chariot/blob/master/Figures/LayeredOverview.png" width="45%" height="45%"/>

3. **Management layer (runtime)**: This is the bottom-most layer and is responsible for management of the runtime system. This layer comprises entities that facilitate autonomous resilience via a self-reconfiguration mechanism based on a closed *sense-plan-act* loop capable of (1) failure avoidance/masking using traditional redundancy mechanisms, (2) failure management to recover from failures, and (3) operations management to handle planned system updates. Entities in this layer can be differentiated into three categories. 
  * First category is the Monitoring Infrastructure, which comprises entities that help "sense" changes by detecting node ingress and egress. Current implementation of CHARIOT uses [ZooKeeper](https://zookeeper.apache.org/) to implement a dynamic monitoring infrastructure. 
  * Second category is the Management Engine, which "plans" for new solution when the system needs to reconfigure itself. CHARIOT uses [Z3 SMT Solver](https://github.com/Z3Prover/z3/) to implement the management engine. 
  * Third and final category is the Deployment Infrastructure, which comprises of distributed Deployment Managers (one per each node) that are responsible for "acting" on commands computed by the management engine. Each deployment manager is capable of managing local (node-specific) applications. Current implementation of CHARIOT using [ZeroMQ](http://zeromq.org/) as the middleware for communication between the management engine and deployment managers.

For interested readers, [this](http://www.dre.vanderbilt.edu/~schmidt/PDF/Pradhan_IoT.pdf) draft paper describes CHARIOT in much more detail.

## Installation Guide
### MongoDB
1. Install MongoDB (tested with MongoDB version 3.2.11).

2. Install a MongoDB GUI (not required but makes it easier to check database contents). We use [Robomongo] (https://robomongo.org/download).

### CHARIOT-ML
1. Install Eclipse (tested with Eclipse [Mars 2](http://www.eclipse.org/downloads/packages/release/Mars/2)).

2. Install CHARIOT-ML as an Eclipse plugin using the following update site:   
   http://scope.isis.vanderbilt.edu/chariot/eclipse/repository
   
   To install a new plugin in Eclipse you should go to [Help -> Install New Software...] and use above update site. Once this installation is complete you will be asked to restart Eclipse.
   
4. To check if the installation was successful, please perform the following tasks:
  * Ensure that you have a running MongoDB server instance. This server can be local or remote. If remote, set *MONGO_ADDRESS* and *MONGO_PORT* environment variables accordingly. You might also have to restart your eclipse instance once these environment variables are set. 
  * Clone the [CHARIOT examples](https://github.com/visor-vu/chariot-examples) repository.
  * Import any one of the available examples as existing project in your restarted Eclipse instance [File->Import...->General->Existing Projects into Workspace]. When browsing the source folder you will see that CHARIOT-ML icons are used for files and keywords are highlighted.
  * Run the CHARIOT-ML interpreters by cleaning the project [Project -> Clean...].
  * Check MongoDB server for a database named *ConfigSpace* which should contain all system description information required by CHARIOT runtime.<commit_msg>Minor update<commit_after>[![Build Status](https://travis-ci.org/visor-vu/chariot.svg?branch=master)](https://travis-ci.org/visor-vu/chariot)

# CHARIOT

## Summary
CHARIOT is a holistic solution that facilitates design, development, and management of distributed systems. Although the current implementation of CHARIOT was designed and tested with use-case scenarios specific to the domain of [extensible Cyber-Physical Systems(CPS)](http://etd.library.vbe.proxy.library.vanderbilt.edu/available/etd-11172016-154749/unrestricted/Pradhan.pdf), the underlying concepts are applicable to distributed systems in general. Following are the key aspects of CHARIOT:
* Design-time, generic system description using follwoing abstract concepts: 
   * The goal/mission of a system and ojectives required to achieve a system's goal
   * Functionalities that are required to satisfy an objective and dependencies between them
   * Replication constraints associated with different functionalities (mainly for redundancy)
   * Component types that provide functionalities (not explicit component instances)
   * Hardware categories and templates (not explicit hardware resources)
* At runtime, depending on the required functionalities and a set of component types, a set component instances and their inter-dependency is computed (this is the software graph)
* Different hardware resources (nodes that can be equipped with various devices) can ingress of egress a cluster dynamically at runtime; as such, at any given time there is a set of available harware resources with links between them (this is the hardware graph)
* The management problem being solved by CHARIOT is that of mapping the software graph onto the hardware graph while satisfying different system constraints

### Vision: Managing extensible CPS at Scale
Cyber-Physical Systems (CPS) have traditionally been designed as closed systems for specific domains. This design philosophy was necessitated by the stringent requirements on system correctness, reliability, security and privacy. However, with increasing push towards open architectures and the emphasis on integration of CPS with Internet of Things (IoT), cloud computing, and online data analytics, as evidenced by the increasing interest in Smart City cyber-physical applications, the trend in CPS design and deployment is transitioning towards a more open and dynamic approach. This results in extensible CPS that are not built as a single function system, but rather as loosely connected, networked platforms comprising subsystems pertaining to different domains. These heterogeneous cyber-physical platforms simultaneously host multi-domain cyber-physical applications and their behavior cannot be encoded a priori, but it evolves over time depending on the hosted applications.

The figure below presents a target system architecture for CHARIOT. Edge nodes are resource constrained nodes that are equipped with various sensors and/ or actuators, and deployed in the physical environment. Management and monitoring infrastructures can be run on these nodes as long running platform services. Applications make use of available resources for sensing, actuating, and non-resource intensive computations. Different middleware solutions can be used by these applications to communicate with each other.

<p align="center">
  <img src="https://github.com/visor-vu/chariot/blob/master/Figures/TargetArchitecture.png" width="75%" height="60%"/>
</p>

All computation cannot be run on edge nodes; edge nodes should run small computations that require real-time response. As such extensible CPS requires us to view CPS challenges from a collaborative perspective, where it is critical to utilize advancement in other computing paradigm such as cloud computing to realize a complex computing paradigm. Resource intensive computations that are not associated with real-time requirement can be deployed on a cloud. This yields a multi-layer architecture whereby application properties and requirements determine associated computation proximity and where they can be deployed.

## Architectural Overview
CHARIOT consists of different entities that can be classified into three layers:

1. **Design layer**: This is the top-most layer and comprises a novel DSML (Domain Specific Modeling Language). This DSML is called CHARIOT-ML and it is built using the [Xtext framework](http://www.eclipse.org/Xtext/). CHARIOT-ML consists of (1) language grammars that are metamodels, and (2) interpreters that traverses user models to retrieve design-time system description.

2. **Data layer**: This is the middle layer. It comprises a well-defined data model that codifies the format in which system information (design-time system descriptions and runtime system representation) must be stored. CHARIOT currently uses [MongoDB](https://www.mongodb.com/) to store system information. This layer helps decouple the design layer (top) from the management layer (bottom).

<p align="center">
  <img src="https://github.com/visor-vu/chariot/blob/master/Figures/LayeredOverview.png" width="45%" height="45%"/>
</p>

3. **Management layer (runtime)**: This is the bottom-most layer and is responsible for management of the runtime system. This layer comprises entities that facilitate autonomous resilience via a self-reconfiguration mechanism based on a closed *sense-plan-act* loop capable of (1) failure avoidance/masking using traditional redundancy mechanisms, (2) failure management to recover from failures, and (3) operations management to handle planned system updates. Entities in this layer can be differentiated into three categories. 
  * First category is the Monitoring Infrastructure, which comprises entities that help "sense" changes by detecting node ingress and egress. Current implementation of CHARIOT uses [ZooKeeper](https://zookeeper.apache.org/) to implement a dynamic monitoring infrastructure. 
  * Second category is the Management Engine, which "plans" for new solution when the system needs to reconfigure itself. CHARIOT uses [Z3 SMT Solver](https://github.com/Z3Prover/z3/) to implement the management engine. 
  * Third and final category is the Deployment Infrastructure, which comprises of distributed Deployment Managers (one per each node) that are responsible for "acting" on commands computed by the management engine. Each deployment manager is capable of managing local (node-specific) applications. Current implementation of CHARIOT using [ZeroMQ](http://zeromq.org/) as the middleware for communication between the management engine and deployment managers.

For interested readers, [this](http://www.dre.vanderbilt.edu/~schmidt/PDF/Pradhan_IoT.pdf) draft paper describes CHARIOT in much more detail.

## Installation Guide
### MongoDB
1. Install MongoDB (tested with MongoDB version 3.2.11).

2. Install a MongoDB GUI (not required but makes it easier to check database contents). We use [Robomongo] (https://robomongo.org/download).

### CHARIOT-ML
1. Install Eclipse (tested with Eclipse [Mars 2](http://www.eclipse.org/downloads/packages/release/Mars/2)).

2. Install CHARIOT-ML as an Eclipse plugin using the following update site:   
   http://scope.isis.vanderbilt.edu/chariot/eclipse/repository
   
   To install a new plugin in Eclipse you should go to [Help -> Install New Software...] and use above update site. Once this installation is complete you will be asked to restart Eclipse.
   
4. To check if the installation was successful, please perform the following tasks:
  * Ensure that you have a running MongoDB server instance. This server can be local or remote. If remote, set *MONGO_ADDRESS* and *MONGO_PORT* environment variables accordingly. You might also have to restart your eclipse instance once these environment variables are set. 
  * Clone the [CHARIOT examples](https://github.com/visor-vu/chariot-examples) repository.
  * Import any one of the available examples as existing project in your restarted Eclipse instance [File->Import...->General->Existing Projects into Workspace]. When browsing the source folder you will see that CHARIOT-ML icons are used for files and keywords are highlighted.
  * Run the CHARIOT-ML interpreters by cleaning the project [Project -> Clean...].
  * Check MongoDB server for a database named *ConfigSpace* which should contain all system description information required by CHARIOT runtime.
{'fraction_non_alphanumeric': 0.05796928225661866, 'fraction_numerical': 0.005259068905755095, 'mean_word_length': 5.111760409057706, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 21, 'https://': 18, 'lorem ipsum': 0, 'www.': 8, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4896723', 'n_tokens_mistral': 4031, 'n_tokens_neox': 3715, 'n_words': 2102}