diff --git a/README.md b/README.md
index 8c238b614270013d68e6a14e73c6370d6dc6a75c..25de82c41d5e29acf56d4b579bbbf4dff14fde9d 100644
--- a/README.md
+++ b/README.md
@@ -22,6 +22,7 @@ Key features and development strategies of !CHAOS are:
"BSON" stands for "binary JSON" - a binary storage format that is JSON inspired.
This distribution merely rips it out of the bson repository into its own.
+Read the [Documentation](control-unit/index.md)
For further documentation please visit:
diff --git a/doc/02_Micro_Unit_Toolkit b/doc/02_Micro_Unit_Toolkit
new file mode 100644
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
diff --git a/doc/config.json b/doc/config.json
new file mode 100644
index 0000000000000000000000000000000000000000..a4205a4a3ef1f0ff91f070ff973498c2ea3f2934
--- /dev/null
+++ b/doc/config.json
@@ -0,0 +1,32 @@
+{
+ "title": "!CHAOS Control System",
+ "tagline": "Control system based on Highly Abstracted and Open Structure",
+ "author": "Claudio Bisegni",
+ "image": "logo_chaos_col.png",
+ "ignore": {
+ "files": ["Work_In_Progress.md"],
+ "folders": ["99_Not_Ready"]
+ },
+ "live": {
+ "clean_urls": true
+ },
+ "html": {
+ "theme": "daux-blue",
+ "breadcrumbs": true,
+ "breadcrumb_separator": "Chevrons",
+ "toggle_code": false,
+ "date_modified": true,
+ "float": true,
+ "inherit_index": true,
+ "links": {
+ "INFN Repo": "https://baltig.infn.it/chaos-lnf-control/chaosframework",
+ "INFN Doc Repo":"https://baltig.infn.it:chaos-lnf-control/chaosframework-doc",
+ "Help/Support/Bugs": "https://baltig.infn.it/chaos-lnf-control/chaosframework/issues",
+ "Made by INFN": "http://www.infn.it"
+ },
+ "edit_on": {
+ "name": "Gitlab",
+ "basepath": "https://baltig.infn.it/chaos-lnf-control/chaosframework"
+ }
+ }
+}
diff --git a/doc/control-unit/external_driver.md b/doc/control-unit/external_driver.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5cd6f84af1d639d40c7cc5e49610b6f10fbc06a
--- /dev/null
+++ b/doc/control-unit/external_driver.md
@@ -0,0 +1,10 @@
+# Control Unit External Driver
+
+[TOC]
+
+External driver are like normal control unit driver with the difference that are divide into two separate physical process:
+* *Control Unit Driver*, is the driver that is specified into metadata server and is associated to CU instance when it is loaded
+* *Remote Unit Driver* is the process built on [Micro Unit Toolkit](../02_Micro_Unit_Toolkit)
+
+
+Control unit toolkit uses ***External Unit Layers***(EUL) to provide
diff --git a/doc/control-unit/external_unit.md b/doc/control-unit/external_unit.md
new file mode 100644
index 0000000000000000000000000000000000000000..1fb7042ae4d168e47a0d114b5867fe074eb70892
--- /dev/null
+++ b/doc/control-unit/external_unit.md
@@ -0,0 +1 @@
+#External Unit
diff --git a/doc/control-unit/index.md b/doc/control-unit/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..f766194ba3975e1ebe0c9e1638856f3ba51d9bfc
--- /dev/null
+++ b/doc/control-unit/index.md
@@ -0,0 +1,4 @@
+# Control Unit Toolkit
+
+The Control Unit Toolkit(CUT) provides a library and interfaces to abstract the device concept.
+Each CU (device) defines a dataset and/or actions/commands that represent respectively the data and the commands that !CHAOS use to handle with control and/or DAQ processes.
diff --git a/doc/control-unit/native_driver.md b/doc/control-unit/native_driver.md
new file mode 100644
index 0000000000000000000000000000000000000000..148dac30066d7b24c4c003ebe18daa76f3f3f6f6
--- /dev/null
+++ b/doc/control-unit/native_driver.md
@@ -0,0 +1 @@
+# Native Control Unit Driver
diff --git a/doc/index.md b/doc/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..e729106095e489acef880197f1fc64c041792e92
--- /dev/null
+++ b/doc/index.md
@@ -0,0 +1,44 @@
+
+
+[TOC]
+
+# Description
+The !CHAOS project aims to develop a new concept of control system and data acquisition framework by providing, with a high level of abstraction, all the services needed for controlling and managing a large scientific, or non-scientific, infrastructure.
+!CHAOS redefines the Control System paradigm by introducing the new concept of Control Service, i.e. a distributed, scalable provider offering, to a general class of clients, high- performance services such as data sharing, commands dispatching, continuous historical data archiving, configuration tools, middle-layer resource management, etc ...
+
+The key features and development strategies of !CHAOS are: scalability of performances and size:
+* integration of all functionalities
+* abstraction of services, devices and data
+* easy and modular customisation
+* extensive data catching for performance boost high-performance internet software technologies.
+
+# Principal Components
+Here are briefly described the components of the system.
+
+##Control Unit (CU)
+CU interfaces with the !CHAOS hardware by using a driver and developing both control and data acquisition.
+At software level, CU is an exe file built using the !CHAOS libraries, developed in C language.
+see documentation [here](control-unit/index.md)
+
+## Execution Unit (EU)
+performs the feedback control of the CU via a dedicated driver. It captures data from CDS, processes them and sends commands to the feedback of the CU.
+
+## Client toolkits (UI)
+monitors data and shows them to the users. The impact of the UI on the infrastructure is strictly related to:
+the quantity of data to monitor;
+the type of the user interface used (command line, web, ...)
+see documentation [here](micro-unit-toolkit/index.md)
+
+## Metadata Server (MDS)
+is aimed to manage configuration metadata of the other components of the architecture. The required characteristics are:
+High availability
+High scalability is not required since the load of the metadata server is not proportional to the workload of the control system, but is only related to the number of system components.
+
+## CHAOS Data Server (CDS)
+is responsible of data archiving and distribution from and to the Control Units, Execution Units and User Interfaces. Data management includes the following activities:
+data storage reading the latest data available; querying historical data.
+CDS should provide the following characteristics: high performances;
+high scalability; multi-threading.
+
+
+link to specialised pages:
diff --git a/doc/logo_chaos_col.png b/doc/logo_chaos_col.png
new file mode 100644
index 0000000000000000000000000000000000000000..9a88623f04bc9d2e227bd7384911995fc4f1b4fc
Binary files /dev/null and b/doc/logo_chaos_col.png differ
diff --git a/doc/mds/index.md b/doc/mds/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..52446d65c6f8eb54a290dd07c63c272384975369
--- /dev/null
+++ b/doc/mds/index.md
@@ -0,0 +1,5 @@
+# Metadata service
+
+[TOC]
+
+The ***Metadata Service***(MDS) is a chaos process that act as separation layer from !CHAOS nodes and backend implementations(live cache, database and storage)
diff --git a/doc/micro-unit-toolkit/http_connection_adapter.md b/doc/micro-unit-toolkit/http_connection_adapter.md
new file mode 100644
index 0000000000000000000000000000000000000000..2be0a8f51c87a731fc893da79d936289c24e992c
--- /dev/null
+++ b/doc/micro-unit-toolkit/http_connection_adapter.md
@@ -0,0 +1,5 @@
+# HTTP Connection Adapter
+
+[TOC]
+
+The ***HTTP Connection Adapter*** (HCA) implements the EUS protocol using a standard web-socket connection sending and receiving JSON message.
diff --git a/doc/micro-unit-toolkit/index.md b/doc/micro-unit-toolkit/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..09cf701347426fd5c17560a094a6f1cf1f608006
--- /dev/null
+++ b/doc/micro-unit-toolkit/index.md
@@ -0,0 +1,80 @@
+# Micro Unit toolkit
+
+[TOC]
+
+The ***Micro Unit Toolkit***(MUT) provides a way to connect with the external unit layer exposed by control unit toolkit. It is build with very little dependency, most of which are included directly in MUT source as amalgamated source file.
+
+## Why another toolkit
+<p align="justify">
+This new toolkit is created keeping in mind that it should compile on most platform starting from a very old operating system and hardware to the new realtime operation system. In general where !CHAOS framework can't be compiled or run the micro unit toolkit permit extends this limitation. The toolkit is the remote counterpart of the [External Unit Server (EUS)](../control-unit/external_unit.md) hosted by the CUT.
+</p>
+
+## Dependency
+The library that are used by the toolkit are:
+* [jsonccp](https://github.com/open-source-parsers/jsoncpp) used for the data serialization
+* [mongoose](https://github.com/cesanta/mongoose) used for web-socket http management
+
+## Architecture
+<p align="justify">
+The internal MUT architecture is base on two different Layers, on that abstract the connection implementation and one that realize the unit implementation. The toolkit is totally developed to an event based interaction with user. The unit toolkit uses the connection adapter to create a connection to the remote EUS and exchange data, with the remote counterpart, with the chosen unit proxy.
+</p>
+<p align="justify">
+The Exchanged data consists on message that are exchanged by each endpoint in an asynchronous way. Each one can, spontaneously, send a message to the other counterpart. The semantic of the messages follow the key/value logic. Different serialization can optimize the way to code this semantic[example json, bson, avro , etc...]
+</p>
+
+### Connection Adapter(CAL)
+<p align="center"> <img src="../img/mut_ca.png"></p>
+<p align="justify">
+The abstract adapter implement all primitive communication for send message and request and contains a queue of received spontaneous message from remote endpoint or response to a request response. The subclass need to implement four abstract method:
+</p>
+```cpp
+virtual int connect() = 0;
+virtual void poll(int32_t milliseconds_wait = 100) = 0;
+virtual int sendRawMessage(chaos::micro_unit_toolkit::data::DataPackUniquePtr& message) = 0;
+virtual int close() = 0;
+```
+
+<p align="justify">
+The subclass need to manage by itself the connection state and a queue of message to send, pool is called repetitively to permit to implementation to send data and receive new message. When something has been received, subclass need to call the below superclass method to send new arrival in the queue of the received messages.
+</p>
+```cpp
+void handleReceivedMessage(chaos::micro_unit_toolkit::data::DataPackSharedPtr& received_message);
+```
+<p align="justify">
+The design is very basic and not use any thread or async things, so every additional feature need to be implemented by the user. In this way the adapter can be adapted also into very bare-bone or limited resources hardware. The abstraction itself implements the external unit logic communication layer exposing this public method:
+</p>
+
+```cpp
+const ConnectionState& getConnectionState() const;
+int sendMessage(data::DataPackUniquePtr& message);
+int sendRequest(data::DataPackUniquePtr& message, uint32_t& request_id);
+bool hasMoreMessage();
+chaos::micro_unit_toolkit::data::DataPackSharedPtr getNextMessage();
+bool hasResponse();
+bool hasResponseAvailable(uint32_t request_id);
+```
+<p align="justify">
+Below is shown the flow of a connection by his states:
+<p align="center"> <img src="../img/mut_connection_flow.png"></p>
+</p>
+
+Implemented superclass and protocols:
+* [http connection adapter](./http_connection_adapter.md)
+
+
+#### HTTP Connection Adapter
+<p align="justify">
+The http connection adapter realize a JSON based protocol transmitter over web-socket connection with the remote EUS exposed by control unit.
+</p>
+
+### Unit Proxy(UPL)
+<p align="center"> <img src="../img/mut_up.png"></p>
+<p align="justify">
+the unit proxy uses the connection and abstract data representation to exchange dat with the [EUS](../control-unit/external_unit.md). In other world the type of connection and serialization are managed at connection level. In any way, in whatever serialization will be created, the messages will ever contains a notions of key and value, so the semantic will never changes.
+</p>
+<p align="justify">
+Unit Proxy is the base class for all implemented unit at this time only the Raw Driver unit is implemented. In future will be implemented the whole Control Unit protocol stack for totally externalize a real CU. Unit proxy realize the base transport layer for unit object, it define the semantic of send and receive message and request.
+</p>
+
+* Message are data that are send o received by each connection endpoint.
+* <p align="justify">Requests are message that need a response by the endpoint that received it. The request with the message also delivers the is of the request. This code need to be send with the message that need to be used as response.</p>
diff --git a/doc/micro-unit-toolkit/raw_driver_unit_proxy.md b/doc/micro-unit-toolkit/raw_driver_unit_proxy.md
new file mode 100644
index 0000000000000000000000000000000000000000..f2cb60a3e6c91b7225243c5d99e35c7286bb4902
--- /dev/null
+++ b/doc/micro-unit-toolkit/raw_driver_unit_proxy.md
@@ -0,0 +1 @@
+# Raw Driver Unit