Update documentation

Update names of images. Remove out-of-date sections and streamline page.

Bug-AGL: SPEC-
Signed-off-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Change-Id: I140cc290204564c4d1f026b2e975f3ce04e2afb9
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/30528

38 files changed, 4045 insertions, 0 deletions

diff --git a/docs/05_Component_Documentation/01_AGL_components.md b/docs/05_Component_Documentation/01_AGL_components.md
new file mode 100644
index 0000000..4aa9a17
--- /dev/null
+++ b/docs/05_Component_Documentation/01_AGL_components.md
@@ -0,0 +1,31 @@
+---
+title: AGL Components
+---
+
+## Components under development within AGL
+
+### Graphics
+
+- [The AGL compositor](02_agl_compositor.md)
+- [DRM lease manager](05_drm_lease_manager.md)
+
+
+### Sound
+
+- [Pipewire & Wireplumber](07_pipewire_wireplumber.md)
+- [IC and Sound Manager](08_Instrument_Cluster_Sound_Management.md)
+
+
+### Policies
+
+- [Rule based arbitrator](04_Rule_Based_Arbitrator.md)
+
+
+### Application Lifecycle and Services
+
+- [Application Framework](Application_Framework/01_Introduction.md)
+
+### Application for Demo
+
+- [Momi Navi](Demo_Application/01_Momi_Navi.md)
+
diff --git a/docs/05_Component_Documentation/02_agl_compositor.md b/docs/05_Component_Documentation/02_agl_compositor.md
new file mode 100644
index 0000000..67b73da
--- /dev/null
+++ b/docs/05_Component_Documentation/02_agl_compositor.md
@@ -0,0 +1,769 @@
+---
+title: agl-compositor
+---
+
+# Wayland compositor
+
+When the AGL project was started, weston was chosen as the compositor, which is
+the reference implementation of a Wayland compositor, while for window management
+functionality it relied on *ivi-shell* (In-Vehicle Infotainment) together
+with an extension, called [wayland-ivi-exension](https://github.com/GENIVI/wayland-ivi-extension).
+
+A demo platform image of AGL comes with a handful of demo applications, done
+with the Qt, which abstracts the protocol communication between the client and
+the compositor. Additional functionality was in place under the form of
+library, to control and signal back to the compositor when applications were
+started, among other things.
+
+Management of applications, starting, running and stopping them is done in AGL
+with AppFW [Application Framework Management](Application_Framework/01_Introduction.md),
+which is an umbrella name to denote the suite of tools and daemons that handle
+all of that. It is integrated with systemd and with the current security model.
+Applications can use AppFW to hang off data, and to pass it down to
+other services. Together with AppFW, applications could tell the compositor
+which application to activate or to switch to.
+
+
+## Simplifying the graphical stack
+
+Trimming down these abstractions, simplifying the way clients interact with the
+compositor, and avoid using modules that aren't really maintained upstream were
+the reasons behind looking at alternatives to ivi-shell. On the desktop,
+[xdg-shell](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/raw/master/stable/xdg-shell/xdg-shell.xml)
+is currently de-facto protocol for handling all window management related
+functionality.
+
+Wayland protocol has a window-like interface embedded into its protocol (called
+wl_shell), but *xdg-shell* has long time ago deprecated it and instead
+of adding it in the wayland protocol namespace, it was integrated
+together with some other useful protocols, into
+[wayland-protocols](https://gitlab.freedesktop.org/wayland/wayland-protocols)
+project.  The whole purpose of wayland-protocols is to enhance the Wayland
+protocol with new functionality and bring new extensions entirely.  Compositors
+are free to implement, modify, enhance, and add new extensions to
+wayland-protocols but they need to do so in consensus.
+
+Besides the core wayland protocol and extended functionality from
+wayland-protocols, a compositor can provide and implement additional protocol
+extensions (custom to that compositor). By using such private extensions we
+align with the AGL project and its requirements, without compromising specific
+functionality and allows to add or improve the current ones. With that in mind,
+the approach was to create a new compositor, called
+[agl-compositor](https://gerrit.automotivelinux.org/gerrit/admin/repos/src/agl-compositor)
+and implement dedicated private extensions, rather than trying to modify weston
+itself, which AGL project would have been required to keep and maintain for
+itself, as a fork.
+
+## A compositor based on libweston
+
+The compositor used currently in AGL, just like weston, is built on top of
+*libweston* and *libweston-desktop*. The latter, among other things, is required
+as it provides the server side implementation of the xdg-shell protocol which
+underlying toolkits (like Qt/Chromium project) makes use of to deliver
+desktop-like functionality. The former is used to provide back-ends and
+rendering support, effectively managing the HW, besides implementing the
+wayland protocol.
+
+The high-level goal of [libweston](https://wayland.pages.freedesktop.org/weston/toc/libweston.html) is
+to decouple the compositor from the shell implementation.
+
+Traditionally, clients were entirely separated from the window manager, the
+desktop environment and the display server. In wayland all these are
+conceptually under the same entity though they are implemented as different
+(UNIX) processes, or as a different namespaces with front and back-end APIs,
+exposed by libraries. The compositor and the shell driving the UI should be
+seen as one and the same, and in practice, this happens on desktop
+environments. For AGL, the shell client can be represented under different
+forms, as well as the fact that the process management has another layer
+baked-in to handle MAC (Mandatory Access Control) labels and use the
+above-mentioned Application Framework. These are all tightly
+integrated and therefore, the AGL compositor will not automatically start the
+shell client, although there's code to handle that.
+
+## Specifying a shell client to be started by the compositor
+
+Nevertheless, one can modify the configuration file, add the shell client path, and the
+compositor will attempt to start it.
+
+```
+[shell-client]
+command=/path/to/your/client/shell
+```
+
+
+
+## Private extensions
+
+Compositors can define and implement custom extensions to further control
+application behaviour. For AGL, we have two private extensions defined.
+One targeted at defining surface roles commonly found in desktop environments
+(like panels, and backgrounds), which a shell client would bind to, and one
+targeted at regular application(s) that might require additional functionality:
+being able to display/activate its own surface or other's application surface,
+implement some kind of split screen management of windows, or
+dialog/pop-ups that exhibit always-on-top property even if the active
+surface has been changed.
+
+![Layers_And_Extensions](images/agl-compositor/drawing_shell.png)
+
+Clients can make use of these private extensions to define other kind of roles
+for instance dialog/pop-ups or full-screen roles, and split windows vertically or
+horizontally. It includes the ability to activate other applications, assuming
+that the surfaces have been created, and the capability of delaying
+presentation for the client shell. Doing so, all the information is displayed
+at once, rather than waiting for the toolkit to map/show the surface.
+
+An application identification mechanism was required to be able to activate
+other clients windows/surfaces. A string-based identifier name was chosen
+which can be used by the client to set an application-based identifier using
+the xdg-shell protocol. While there's nothing stopping the client to avoid
+doing that, specifically, to avoid assigning an application identifier,
+the compositor won't be able to find which surfaces matches to a particular
+client, if one would want to activate/display it at some time in the future.
+
+### agl-shell
+
+Client shellls can make use of this protocol to define panels and background
+roles for different surfaces. It includes to ability to activate other
+applications, assuming that those are already running. Activation happens by
+using using the app_id, respectively using set_app_id request as defined by the
+xdg-shell protocol. Established client-side implementation of the xdg-shelll
+protocol will have a function exposed which can be used to set an application
+identifier.  Further more, the compositor will not present/display anything to
+the user as long the `ready()` is not requested. So, after creating the surfaces
+assigning them panel and/or background roles, and they're fully loaded,
+the client can then issue `ready()` request and the compositor will start
+presenting.
+
+Please consult the [protocol file](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/agl-compositor.git;a=blob_plain;f=protocol/agl-shell.xml;hb=refs/heads/master)
+as that is the authoritative way of getting the latest version.
+
+#### V2 updates
+
+Version 2 of the agl-shell protocol, while it is is not obligatory to be
+supported by the shell client, it adds two new events: bound_ok and bound_fail
+events.
+
+It has been observed that in some cases where we do not explicitly have a knob
+in the toolkit to tell whether the application is a regular one (which doesn't
+need to bind to the agl-shell protocol) or a one that needs to implement
+agl-shell protocol might result in terminating the wayland connection.
+
+That happens because we can't have multiple clients bind to the agl-shell
+protocol interface and was particularly visible when using regular
+flutter applications with other shell clients (Qt homescreen, or WAM/chromum),
+basically mashing together different kind of toolkits in the same image. Once
+a client has already bound to the agl-shell protocol interface any other client
+that attempts to do same will get its wayland connection severed and the
+application will be terminated.
+
+These two events provide a race-free method in which the clients can tell if
+they're in charge (of being the shell client) or their just regular
+applications. Explicitly implementing this protocol if you have other means to
+specify which type of application it is running wouldn't be required nor
+necessary. But by using the protocol we can provide the same thing,
+programmatically, without fearing that the wayland connection might be
+severed, and implicitly taking down the application.
+
+#### V3 updates
+
+Version 3 of the agl-shell protocol adds 4 more events to signal out when the
+application state was changed: started, activated, deactivated and terminated.
+
+Version 3 update was mostly prompted by an issue with start-up of applications
+but also is part of the first steps to reduce and simplify a bit more
+activation handling in the compositor.  Specifically with this protocol update,
+we can correctly orchestrate start-up and activation of applications.
+
+At the moment of adding this protocol update, the default compositor behaviour
+is to display/activate applications as soon they're started, a feature which
+we've called activate-by-default (and which is turned on by default).
+But users can choose to disable that in such a way that activation is entirely
+driven the shell client.
+
+Implicitly having this activate-by-default papered over various
+issue when don't have that activation by default turned on. Supporting both
+use-cases (activate-by-default, on and off) turned out to be cluster of
+problems and regression over time. Not only that the amount of complexity in
+the compositor is unwarranted and can simplified by telling the shell client
+handle any window management interaction on its own.
+
+Further more, with this protocol update we also includes some events already
+present in the agl-shell-desktop protocol like  deactivate and terminate.
+
+#### V4 updates
+
+Version 4 of the agl-shell protocol brings a new request,
+"set_activate_region". This is a hint for the compositor to use a custom area
+for activation, rather than inferring the activation area from the panels.
+This is a work-around designed for toolkits which can't handle multiple
+surfaces at the same, such that it can this achieve the same functionality as
+having multiple surfaces, but instead have just a single main surface to
+handle. The compositor will place other applications in the designated
+activation region, and will activate/deactivate surfaces only that in region.
+With a custom activation area that leaves portions of the output available to
+the toolkit this means it can achieve a similar graphical outcome as if there
+are panels. All the toolkits, including Qt are now using this approach, with only
+CI using distinct surfaces with panels.
+
+#### V5 updates
+
+Version 5 of the agl-shell protocol brings a new request, "deactivate_app".
+Similar to the activate request, this will hide the current active application.
+Depending on the window role, this request will either display the previously
+active window (or the background in case there's no previously active surface)
+or temporarily (or until a 'activate_app' is called upon) hide the surface.
+
+#### V6 updates
+
+Version 6 of the agl-shell protocol, brings two new request, "set_app_float" and
+"set_app_normal". The first one is a method to change the surface role, either
+on the fly, or at start-up to behave like a dialog/pop-up window, which can be
+positioned anywhere on the output. The later one, is useful to return the main
+original surface role, as maximized.
+
+#### V7 updates
+
+Version 7 of the agl-shell protocol, brings one new request, "set_app_fullscreen".
+This is similar to "set_app_float", but it changes the surface role to fullscreen.
+Going back to the orignal, maximized role should be with "set_app_normal".
+
+#### V8 updates
+
+Version 8 of the agl-shell protocol, adds a new request, "set_app_output", and
+a new event, "app_on_output". This request/event is useful to migrate
+applications from one output to another and signal out when that happens.
+
+#### V9 updates
+
+Version 9 of the agl-shell protocol, adds a new request, "set_app_position". This
+request only makes sense for float type of surface, which was previously set with
+"set_app_float".
+
+#### V10 updates
+
+Version 10 of the agl-shell protocol, adds a new request, "set_app_scale".
+Similar to the "set_app_position", the surface role must be a floating type,
+before using this request. The app scale request is actually a resize
+hint for the client to change its dimensions to the one specified in the
+request arguments. The client should use [wp_viewporter
+interface](https://wayland.app/protocols/viewporter#wp_viewporter) to perform
+cropping and scaling.
+
+#### V11 updates
+
+Version 11 of the agl-shell protocol, adds a new request "set_app_split".  This
+request only handles a single level of tiling for practical reasons as to keep
+implementation simple and straight forward. Apart from the usual, tile
+horizontally, and vertically, two arguments can be used to customize handling.
+One defines the width of the split window, such that clients can specify, in
+absolute values, the size of the split window. The other is about keeping the
+split window always present when activating other windows.
+
+By default when activating a new windows, the split window roles are destroyed
+and new activated window will be put in front. Making the split window sticky
+would avoid doing that. Obviously trying to activate a window already active,
+which has the sticky role won't be possible (it is already displayed).
+
+### agl-shell-desktop (deprecated, will be removed in future, see gRPC proxy)
+
+This extension is targeted at keeping some of the functionally already
+established in AGL as to a) allow applications display/activate other
+surfaces/application window, and b) set further roles, specially dialog/window
+pop-ups and split-type of surfaces.
+
+Clients can make use of this protocol to set further roles, like independently
+positioned pop-up dialog windows, split type of surfaces or fullscreen ones.
+Additional roles, and implicitly functionality can be added by extending the
+protocol. These roles serve as hints for the compositor and should be used
+before the actual surface creation takes place, such that the compositor can
+take the necessary steps to satisfy those requirements.
+
+Please consult the [protocol file](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/agl-compositor.git;a=blob_plain;f=protocol/agl-shell-desktop.xml;hb=refs/heads/master)
+as that is the authoritative way of getting the latest version.
+
+#### Additional surface roles in agl-shell-desktop
+
+Like mentioned earlier, the compositor is already making use of some (internal)
+roles, and with this extension we add some further ones. These are:
+
+* split (there's vertical and a horizontal one)
+* fullscreen
+* dialog/pop-up
+
+Internally these are encoded with different values such that there's a
+translation needed, between the protocol values and the internal ones.  Besides
+the roles, additional data can to be passed on, but only depending on the role.
+It is highly recommend **to avoid** using the protocol to pass down information
+between different applications using this communication channel. It is only
+intended to help out with demo applications. Other sharing mechanism are
+available in the AGL project that can satisfy those requirements.
+
+#### Receiving application state events from (other) applications
+
+agl-shell-desktop exposes two events which client can install handlers for, one
+that signals when regular xdg application have been created, and one that
+signals state changes (active/hidden) as well as destroyed/no longer present
+surfaces. These events can be useful to add additional functionality if
+needed.
+
+#### Activating (other) applications
+
+Both agl-shell and agl-shell-desktop have requests to activate other
+application based on their xdg-shell app_id. In case the application is
+present/running, it will attempt to make the surface backing that application
+the current activate one, with each output having independently active
+surfaces.
+
+## gRPC proxy for window management
+
+The gRPC proxy is an alternative to allow management of windows,
+without the need for clients to "speak" native Wayland C code.  Most major
+languages have RPC bindings, and in AGL clients do not touch Wayland code
+natively, using most of the time toolkits. It seemed reasonably to use gRPC
+as a way to interact with the compositor. The way this works is that
+there's proxy daemon started by the compositor which translates the gRPC
+calls to Wayland ones, using agl-shell protocol. Events coming from the
+compositor are handled by subscribing to RPC stream events, such that
+clients can act upon as well, so it is not just one way interaction.
+
+With respect to window management: placement, movement, and surface role
+changes all should, and can be done with RPC. Some of the calls, specifically
+background set-up or activation area, are still required to happen prior or
+require wayland primitives which can't be passed between processes, so those
+can't be used with RPC proxy.
+
+In terms of API, the following are available: activation/deactivation,
+role management, and events. All the message arguments are self-explanatory,
+requiring always an app_id, in form of string and possibly an output, in
+form a string as well. Toolkits can set/retrieve this information so refer
+to the respective toolkit. At the wayland level, the app_id is set/get
+with [xdg-shell](https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_app_id)
+whereas output from [wl_output interface](https://wayland.app/protocols/wayland#wl_output:event:name)
+
+Activation and deactivation of applications:
+
+```
+rpc ActivateApp(ActivateRequest)         returns (ActivateResponse) {}
+rpc DeactivateApp(DeactivateRequest)     returns (DeactivateResponse) {}
+```
+With the following message arguments:
+
+```
+message ActivateRequest {
+       string app_id = 1;
+       string output_name = 2;
+}
+
+message ActivateResponse {
+};
+
+
+message DeactivateRequest {
+       string app_id = 1;
+};
+
+message DeactivateResponse {
+};
+```
+
+Management of surface roles can be done with these requests:
+
+
+```
+rpc SetAppSplit(SplitRequest)            returns  (SplitResponse) {}
+rpc SetAppFloat(FloatRequest)            returns  (FloatResponse) {}
+rpc SetAppFullscreen(FullscreenRequest)  returns  (FullscreenResponse) {}
+rpc AppStatusState(AppStateRequest)      returns  (stream AppStateResponse) {}
+rpc GetOutputs(OutputRequest)            returns  (ListOutputResponse) {}
+rpc SetAppNormal(NormalRequest)          returns  (NormalResponse) {}
+rpc SetAppOnOutput(AppOnOutputRequest)   returns  (AppOnOutputResponse) {}
+rpc SetAppPosition(AppPositionRequest)   returns  (AppPositionResponse) {}
+rpc SetAppScale(AppScaleRequest)         returns  (AppScaleResponse) {}
+```
+
+Message arguments are:
+
+```
+message SplitRequest {
+       string app_id = 1;
+       int32 tile_orientation = 2;
+       int32 width = 3;
+       int32 sticky = 4;
+       string output_name = 5;
+}
+
+message SplitResponse {
+};
+
+message FloatRequest {
+       string app_id = 1;
+       int32 x_pos = 2;
+       int32 y_pos = 3;
+};
+
+message FloatResponse {
+};
+
+message NormalRequest {
+        string app_id = 1;
+};
+
+message NormalResponse {
+};
+
+message FullscreenRequest {
+        string app_id = 1;
+};
+
+message FullscreenResponse {
+};
+
+message AppOnOutputRequest {
+        string app_id = 1;
+        string output = 2;
+};
+
+message AppOnOutputResponse {
+};
+
+message AppPositionRequest {
+       string app_id = 1;
+       int32 x = 2;
+       int32 y = 3;
+};
+
+message AppPositionResponse {
+};
+
+message AppScaleRequest {
+       string app_id = 1;
+       int32 width = 2;
+       int32 height = 3;
+};
+
+message AppScaleResponse {
+};
+```
+
+Events which clients can subscribe to:
+
+```
+rpc AppStatusState(AppStateRequest) returns (stream AppStateResponse) {}
+```
+
+With the message arguments:
+
+```
+message AppStateRequest {
+};
+
+message AppStateResponse {
+        int32 state = 1;
+        string app_id = 2;
+};
+```
+
+A C++ client implementation the gRPC API can be found in [agl-shell-activator](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/agl-shell-activator.git;a=tree;h=refs/heads/master;hb=refs/heads/master)
+or in [window-management-client-grpc](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/window-management-client-grpc.git;a=tree;h=refs/heads/master;hb=refs/heads/master).
+
+## Explicit output
+
+The activation and setting surface roles requires passing a Wayland output
+(wl_output).  The output is the wayland interface representation of an output
+and is **mandatory** to pass it down to the compositor when activating a surface.
+Clients can retrieve it (the output) if they wish to place the surface on other
+outputs by using the toolkits that expose the Wayland objects.  A human-like
+representation is provided by either the toolkit, or by using other extensions
+implemented by the client, for instance [xdg-output](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/raw/master/unstable/xdg-output/xdg-output-unstable-v1.xml)
+is the one recommended way and provides a mapping between a human
+representation of the output and the wayland one.
+
+One can also choose the output where the application can start, by configuring
+directly the AGL compositor. Under the `[output]` section one can use
+`agl-shell-app-id=appid` restart the AGL compositor unitd systemd service and
+start the application. Currently this *only* applies to regular applications, the
+client shell having to handle it in the code.
+
+## Available toolkits, application conversions and available eco-systems
+
+Users and OEM vendors alike have the possibility, depending on their use-cases,
+to either use some kind of a toolkit (Qt/GTK) for writing  application,
+or use plain C and the wayland library to communicate with the compositor
+directly, without any toolkit abstraction.
+
+Currently, the demo applications in AGL use the Qt platform with Chromium being
+at this phase, a second-class citizen, being currently in the works of
+achieving the same level of integration as QtWayland (the underlying library that
+abstracts the Wayland interaction) has at this moment. The Qt platform has
+long been favoured in embedded systems so it feels natural why AGL project
+chose it over other alternatives.  In the same time, as web applications are
+for quite some time now permeating the application development scene, it also
+felt natural to add support for a runtime that gives that option, which in AGL
+was achieved with the help of the Chromium project.
+
+For normal applications, not needing the ability to activate or displaying
+other's application surface, would basically mean that it would use what the
+toolkit has to offer, simplifying the application handling even more.  Under
+Qt, the client shell can use QPA (Qt Platform Abstraction) to gain access to
+Wayland primitives, and implicitly is being able use the private extensions.
+
+![Architecture Diagram](images/agl-compositor/arch_diagram.png)
+
+On the Chromium side of things, that happens indirectly, as Chromium doesn't
+expose the Wayland primitives. Not only that, but on the Chromium platform,
+there's another mid-layer component, called [WAM](https://github.com/webosose/wam)
+(WebApplicationManager) with the purpose of handling web applications life-cycle.
+
+So, controlling and passing information from a web application, that resembles
+that of a shell client, has to travel more than a few levels in the software
+stack, until it reaches the lower layers in Chromium where the Wayland
+communication and interaction takes place. Support for the private extension
+was done at the Ozone interface abstraction, which Chromium projects uses now
+to handle the display/graphical interaction with the lower stack levels.
+
+## How to integrate or incorporate your own UI
+
+The Minimum Viable Product (MV) to be able to switch/change/replace the current
+UI, depending on toolkit is to call `set_background()` and `set_ready()` requests
+from the agl-shell client protocol.
+
+This means that the toolkits need to provides access to Wayland primitives,
+exposing them in a such that they can reach the client code. For instance,
+Qt uses [QPA](https://wiki.qt.io/Qt_Platform_Abstraction), while
+GTK can also expose it through similar ways.
+Chromium/CEF and flutter platform do not explicitly expose the windowing system
+(and implictly Wayland) and have that implemented at a lower level.
+
+Further more, depending on the needs, one would also need to either use the
+gRPC proxy API or just agl-shell protocol on its own. For instance for Qt and
+flutter we now use a combination of both. In Qt, we use QPA and Wayland native
+code to set the [background surface](https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/homescreen.git;a=blob;f=homescreen/src/main.cpp;h=a98a15bb0113f3b28c1766e79c5d3f2d0b20fac4;hb=refs/heads/master#l255),
+while activation/deactivation and anything else is handled using gRPC API,
+but in the [same application](https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/homescreen.git;a=blob;f=homescreen/src/main.cpp;h=a98a15bb0113f3b28c1766e79c5d3f2d0b20fac4;hb=refs/heads/master#l355).
+
+In flutter because we can't reach Wayland code
+from within the client, we handle the Wayland part in the
+[flutter embedder](https://github.com/toyota-connected/ivi-homescreen/blob/agl/shell/wayland/window.cc#L95-L121)
+whereas the activation is handled in [flutter-ics-homescreen](https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/flutter-ics-homescreen.git;a=blob;f=lib/data/data_providers/app_launcher.dart;h=8762643dba7f5a6e3ad2051749e30239743e759a;hb=HEAD)
+
+Similarly, CEF/Chromium has the same thing, the background and ready to present
+request is handled at the lower levels.
+
+### Simple shell client examples
+
+An alternative to using toolkits is to avoid using any of them and
+instead use native Wayland C code to create a simple shell client. This
+means the client needs to manage everything, including redrawing the
+background surface.
+
+An example of that is
+[native-shell-client](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/native-shell-client.git;a=summary)
+that is being used in the kvm images as a barebone shell client. Because that
+just sets a black background matching the entire output you can have a
+dedicated client that basically displays or mimics being fullscreen
+(although technically it's set to maximized).
+
+## Streaming buffers and receiving events to and from remote outputs
+
+Quite a common feature, in the infotainment market, is the ability to stream
+out buffers/data to remote outputs. For instance, super-imposing the navigation
+application, between the speedometer and tachometer, in the IC (Instrument
+Cluster) of a car is such a scenario. Just like weston, the AGL compositor is
+capable of loading up libweston modules and make use of them. And just like
+weston, the AGL compositor loads up the remoting-plugin to achieve the same
+thing.
+
+The remoting-plugin uses the DRM virtual output API from libweston together
+with gstreamer pipeline to capture, using DMA buffers, the DRM output and to
+stream it, remotely to another machine. They can be over the network, or
+locally.
+
+Further more, to cope with situations where the output is just a
+panel/display, without some kind of compositor driving it, the necessity of
+handling input events is an important feature to have, giving the user to
+possibility to manipulate the application/environment as he or she seems fit.
+
+The compositor loads a plug-in that streams out the buffers to an output
+remotely, with another plug-in was used to handle the input events. The events,
+which are sent back from the display to the compositor, are generated with
+the help of wayland-eque protocol that works over the network, called
+[Waltham](https://github.com/waltham/waltham). This solution was deprecated
+and removed a while back, with an alternative in the works to achieve
+the same functionality.
+
+Together, they provide proper means to achieve a seamless integration with
+other display devices in the car cabin.
+
+## Policies and Role Base Arbitration
+
+The compositor contains an API useful for implementing user-defined policies.
+It contains a policy engine, and installs by default an allow-all kind of
+policy. The policy engine controls if the client using the private extensions
+is permitted to perform those calls. Not only that, but with some policies, it
+won't allow the client to bind to the interfaces in the first place. That
+happens with the deny-all policy, which is able to retrieve the client's
+SMACK label and compares it with the ones statically defined.
+
+In the works, there's a new policy model, called [Role Based
+Arbitration](https://gerrit.automotivelinux.org/gerrit/admin/repos/staging/rba).
+Internally, how it works, should be found at [RBA](04_Rule_Based_Arbitrator.md).
+While the other two policies are embedded into the compositor, the RBA policy
+model is an off the-shell policy.  Obviously, vendors and users can hook up
+their own policies, just like RBA did.  These all work towards satisfying
+the driver distraction mitigation requirement for the AGL project, as to avoid
+overwhelming the driver with too much information.
+
+Users wanting  to create their own policy should create a specialized version
+of the callbacks defined in `struct ivi_policy_api`.
+
+As there's no dynamic loading of policies you'll need to recompile the compositor
+with that policy in mind, specifically like the following:
+
+	$ meson -Dprefix=/path/to/install-compositor/ -Dpolicy-default=my_policy build_directory
+
+The default policy found in src/policy-default.c should more than sufficient to
+get started on creating new ones. Users can either re-purpose the default
+policy or create a new one entirely different, based on their needs.
+
+These are hooks in place by the policy engine control the creation, committing
+and activation of surfaces (`ivi_policy_api::surface_create()`,
+`ivi_policy_api::surface_commited()`, `ivi_policy_api::surface_activate()`),
+among other situations.
+
+Users can customize the hooks by using some sort of database to retrieve the
+application name to compare against, or incorporate some kind of policy rule
+engine.  Alternatively, one can use the deny-all policy engine which allows the
+top panel applications to be used/displayed as permitted applications.
+
+### Reactive rules
+
+The policy engine is stateful,  and allows the ability to inject back events,
+such that it allows the user to add custom rules into a policy and, depending
+on the event received by the policy engine, to execute a rule match for that
+event. Further more, the framework allows adding new states and events and the
+default implementation has code for handling events like showing or hiding the
+application specified in the policy rule.  The most common example to exemplify
+this feature is the ability to show a custom application, like displaying the
+rear view camera application, when the automobile has been put in reverse.
+
+For deadling with these kind of rules, `ivi_policy_api::policy_rule_allow_to_add()`
+can be used to control if policy rules could be added or not. Finally, we have
+`ivi_policy_api::policy_rule_try_event()` which is executed for each policy
+rule added, by using the policy API `ivi_policy_add()` function.
+
+By default the policy framework it will add the 'show', and 'hide' events and
+the 'start', 'stop' and 'reverse' states. An special type, assigned by default
+is 'invalid'.  A **state change** has to be propagated to the compositor, which can
+happen by using `ivi_policy_state_change()` function, and which signals the
+compositor the state change took place, in order to apply the policy rules, and
+implicitly to call the event handler `ivi_policy_api::policy_rule_try_event()`.
+
+## Back-ends and specific options for agl-compositor
+
+The compositor has support for the following back-ends:
+
+* **DRM/KMS** - runs a stand-alone back-end, uses Direct Rendering Manager/Kernel
+  Modesetting and evdev, that is utilizes and runs on real or virtualized HW
+  (qemu/Vbox/etc).
+* **Wayland** - runs as a Wayland application, nested in another Wayland compositor
+  instance
+* **X11** - run as a x11 application, nested in a X11 display server instance
+
+### Building and running the compositor on different platforms
+
+The compositor can run on desktop machines as easily as it does on AGL
+platform. It should infer, depending on the environment, if it is being
+compiled with the AGL SDK, or with the host build system.  Running would also
+be inferred from the environment.
+
+The compositor has some additional configuration options like:
+
+* `--debug` - enables the screenshooter interface, useful if one would want to
+  take a screenshot using `agl-screenshooter` client. This might be seen as a
+  security risk to it only be enabled in the AGL platform if built with agl-devel
+  DISTRO FEATURES.
+
+Additional configuration ini options have been added to help with the CI
+integration. Worth mentioning are:
+
+* `activate-by-default=[true]` - if the surface of the client should be
+  displayed when the application started. Present in the `[core]` section.
+  By default set to `true`. Setting it to `false` will not activate,
+  by default, the client's surface when started.
+* `hide-cursor=[false]` - do not advertise pointer/cursor to clients. Present
+  in the `[core]` section.
+
+## Running with software rendering
+
+By default the compositor will attempt to use the GL-renderer, and implicitly
+the GPU. One could instead use the CPU, by making use of the Pixman library. To
+use it in the compositor append `--use-pixman` to the command line. This purely
+software approach has the benefit that would not rely at all on any GL
+implementatation or library. In constrast, even if the GL-renderer is used,
+in some situations it won't be able to use the GPU supported implementation
+and fallback to sofware based one, and for instance that might happen when
+running in virtualized environments.
+
+Both approaches could end up not actually using the GPU, but the latter does
+actually use the GL library and perform the operations in software, while the
+former does not use any GL whatsover. All back-ends support disabling the
+GL-render to make sure it does not interfere with the composing process.
+
+## Multiple output set-up and touch input devices
+
+There's no deterministic way in which the compositor enables the outputs and
+depending on the input devices, specifically touch input devices, and the way
+the connectors are wired, a touch input device might be associated with a
+different output than the one intended.
+
+A consistent way, that survives a reboot, is to use
+[udev rules](https://man7.org/linux/man-pages/man7/udev.7.html), which
+libweston would be able to use such that a particular output is tied/associated
+to a particular touch input device.
+
+For instance, assuming that you have a set-up consisting of 4 outputs, a 4
+touch input devices, when the outputs are being enabled the compositor
+front-end will associate all 4 touch input device -- if they haven't been
+previously being associated to a particular output, to the first enabled
+output.
+
+In order to avoid that, and associate each touch input device to
+their respective output an udev rule can be installed, for the default
+seat (named `seat0`).
+
+Example of a udev rule:
+
+```
+SUBSYSTEM=="input", ATTRS{idVendor}=="222a", ATTRS{idProduct}=="004a", OWNER="display", ENV{ID_SEAT}="seat0", ENV{WL_OUTPUT}="HDMI-A-1"
+SUBSYSTEM=="input", ATTRS{idVendor}=="222a", ATTRS{idProduct}=="004b", OWNER="display", ENV{ID_SEAT}="seat0", ENV{WL_OUTPUT}="HDMI-A-2"
+SUBSYSTEM=="input", ATTRS{idVendor}=="222a", ATTRS{idProduct}=="004c", OWNER="display", ENV{ID_SEAT}="seat0", ENV{WL_OUTPUT}="HDMI-A-3"
+SUBSYSTEM=="input", ATTRS{idVendor}=="222a", ATTRS{idProduct}=="004d", OWNER="display", ENV{ID_SEAT}="seat0", ENV{WL_OUTPUT}="HDMI-A-4"
+```
+
+Add the following under `/etc/udev/rules.d/91-output.rules` and reload udev
+rules for these changes to take effect:
+
+	$ udevadm control --reload-rules && udevadm trigger
+
+Note that in the above example, we use physical seat, named `seat0` which is
+the default physical seat. You can verify that these changes have been applied by
+checking the compositor logs (under `/run/platform/display/compositor.log` file)
+You should be seeing `CONNECTOR-NO by udev` message like the following:
+
+```
+associating input device event0 with output HDMI-A-1 (HDMI-A-1 by udev)
+```
+
+vs
+
+```
+associating input device event0 with output HDMI-A-2 (none by udev)
+```
+
+where the rules are either incorrect or badly written.
+
+Retrieving device attributes could be done archaically using `lsusb` or `lspci`
+or using `udevadm info -a /dev/input/event*` which can provide with a multitude
+of attributes to use. In our above example we only relied `idVendor` and
+`idProduct` but potentially other attributes might be used.
diff --git a/docs/05_Component_Documentation/04_Rule_Based_Arbitrator.md b/docs/05_Component_Documentation/04_Rule_Based_Arbitrator.md
new file mode 100644
index 0000000..e1a311d
--- /dev/null
+++ b/docs/05_Component_Documentation/04_Rule_Based_Arbitrator.md
@@ -0,0 +1,1207 @@
+---
+title: Rule Based Arbitrator 
+---
+
+# RBA
+
+Rule Based Arbitrator (RBA) decides which of the content to display when a large number of contents to be displayed on the cockpit display device (CID, meter, HUD, etc.) occur simultaneously under a certain rule (arbitration).
+
+### 1. Overview
+
+#### 1.1 Purpose of this document
+
+This document describes the syntax of the Rule-based Arbitration Model.
+
+#### 1.2 Basic syntax
+
+The basic syntax of the Rule-based Arbitration Model is as follows.
+
+![Basic syntax](images/rba/Basic_syntax.png)
+
+Define the properties of the model element in {} after declaration of Model element keyword,　Model element ID. Each property depends on the element. The properties of the model element may also define other model elements.
+
+#### 1.3 Relationship between files and Model definitions
+
+The Rule-based Arbitration Model can be defined in multiple files. (The extension of the file will be ".rba") Firstly, define the Package model element in the file.
+
+Areas.rba
+```shell
+Package AreasPackage {
+
+}
+```
+Content.rba
+```shell
+Package ContentsPackage {
+
+}
+```
+
+#### 1.4 Structure of Rule-based Arbitration Model
+
+The elements of the Rule-based Arbitration Model are as follows. Each inheritance relationship between elements is defined and expresses elements that can be described in PackagableElement.
+
+![model](images/rba/model.png)
+
+#### 1.5 Notation of Syntax Definition
+
+For Model element
+
+syntax:
+```shell
+Package [ID] {
+  description: [String]
+  [PackagableElement]
+}
+```
+
+Description:
+
+| Syntax element            | Description  |
+| :---                      |    :----     |
+| description:	0..1        | Description  |
+| [PackagableElement]	*   | Child element Package,Display,Size,Constraint,PostConstraint,Scene,Event,Rule,Area,AreaSet,ViewContent,ViewContentSet|
+
+The multiplicity is expressed as follows:
+
+| Expression of multiplicity	| Description |
+| :---                          | :---        |
+| *	                        | 0 or more   |
+| 1..*                          | 1 or more   |
+| 1	                        | 1           |
+| 0..1	                        | 0 or 1      |
+
+Description of [] notation is as follows:
+
+| Syntax element            | Description  |
+| :---                      |    :----     |
+| [ID]			    | ID. A character string in which the first character is not a number. Only _ can be used for symbols, Space cannot be used.
+| [String] 		    | An arbitrary character string. specify it by enclosing with "". |
+| [Number] 		    | An integer that is greater than equal 0. |
+| [expression] 		    | An expression whose return value is a property type. |
+| [<Model element keyword\>] | Definition of other Model elements. Sometimes an abstract class is specified. |
+| [ID of A]		    | Reference to other Model elements. A represents an element. |
+| [X\|Y]		    | Indicates that you can describe X or Y. |
+
+### 2. Common
+
+#### 2.1 Package
+
+The Package element is the root element in the file. It has PackagableElement as a Child element and groups PackagableElements in arbitrary units.
+
+syntax:
+```shell
+Package [ID] {
+  description: [String]
+  [PackagableElement]
+}
+```
+
+| Syntax element            | Description  |
+| :---                      |    :----     |
+| description:	0..1        | Description  |
+| [PackagableElement]	*   | Child element Package,Display,Size,Constraint,PostConstraint,Scene,Event,Rule,Area,AreaSet,ViewContent,ViewContentSet|
+
+Description example:
+```shell
+Package SamplePackage {
+	description: "This is a sample Packege"
+	Area SampleArea {
+		arbitrationPolicy: DEFAULT
+		sizeReference: SampleSize1
+		visibility: NONE_VALUE
+		zorder: 3
+	}
+	ViewContent SampleContent {
+		allocatable: [SampleArea1]
+		State NORMAL {
+			priority: STANDARD_VALUE
+		}
+	}
+}
+```
+
+#### 2.2 Size
+
+Size is the size of Area and ViewContent.
+
+Syntax:
+
+```shell
+Size [ID] {
+  description: [String]
+  width: [Number]
+  height: [Number]
+}
+```
+
+| Syntax element            | Description  |
+| :---                      |    :----     |
+| description:	0..1	    | Description of Size element |
+| width: 1	            | width  |
+| height:	1	    | height |
+
+Description example:
+```shell
+Size ScreenSize {
+	description: " Screen size"
+	width: 200
+	height: 200
+}
+```
+
+#### 2.3 Project
+
+The Project element is an element that can be defined only once in one project.
+Like The Package element, it can be defined directly under the file.
+
+Syntax:
+```shell
+Project {
+  version: [String]
+}
+```
+
+| Syntax element            | Description  |
+| :---                      |    :----     |
+|version:	1|	Version of the Project|
+
+Description example:
+```shell
+Project {
+	version: "version 1.0"
+}
+```
+
+
+### 3. Area
+
+Area is a frame to display the ViewContent on the screen. Only one ViewContent is allocated to one Area at most. Since Arbitration is executed for each Area, the Arbitration Policy is defined.
+
+Syntax:
+
+```shell
+Area [ID] {
+  description: [String]
+  arbitrationPolicy: [DEFAULT | FIRST_COME_FIRST | LAST_COME_FIRST | PRIORITY_FIRST_COME_FIRST | PRIORITY_LAST_COME_FIRST]
+  [[Size]| sizeReference:[ID of Size]]
+  [visibility|priority]:[Number|Expression]
+  zorder:[Number|Expression]
+}
+```
+
+| Syntax element |	Description |
+| :---                      |    :----     |
+| description:	0..1 | Description |
+| arbitrationPolicy: 0..1 | Arbitration Policy for Area. Refer to "Types of Arbitration Policy" for the policies which can be specified. If not specified, consider it as "DEFAULT".
+| [Size\|sizeReference:]	1..* | Size: Size definition.|
+|| sizeReference: Reference to Size definition.|
+|| ※One or more definitions of either Size or sizeReference are needed. Multiple definitions should be defined consecutively.|
+| [visibility\|priority]:	1	| Value of Area. Describe the relative value for other Areas as an expression or set a numerical value.|
+|| The following predefined value can be set as a String. NONE_VALUE, STANDARD_VALUE, MIN_VALUE, MAX_VALUE See " Value / Z order definition" for details. |
+| zorder:	1 | Z order of Area. Describe the relative Z order for other Areas as an expression or set a numerical value. The following predefined value can be set as a String. |
+||NONE_VALUE, STANDARD_VALUE, MIN_VALUE, MAX_VALUE See " Value / Z order definition" for details. |
+
+
+
+Types of Arbitration Policy
+
+| Arbitration Policy           | Description  |
+| :---                      |    :----     |
+| DEFAULT | Same as Priority and First Come First Arbitration. If the Arbitration Policy is not specified, it will be this type.|
+| FIRST_COME_FIRST | First Come First Arbitration. Give priority to the request which occurred first. |
+| LAST_COME_FIRST | Last Come First Arbitration. Give priority to the request which occurred later. |
+| PRIORITY_FIRST_COME_FIRST | Priority and First Come First Arbitration. It follows the priority set to the Content. If the priority is the same, give priority to the request which occurred first. |
+| PRIORITY_LAST_COME_FIRST | Priority and Last Come First Arbitration. It follows the priority set to the Content. If the priority is the same, give priority to the request which occurred later.|
+
+Description example:
+```shell
+Area SampleArea {
+	description: "This is a sample Area."
+	arbitrationPolicy: DEFAULT
+	Size Default {
+		width: 200
+		height: 150
+	}
+	sizeReference: SampleSize1
+	visibility: NONE_VALUE
+	zorder: 3
+}
+```
+
+### 4. Value / Z order definition
+
+Values (visibility or priority) of area is the order of arbitrating of the area. The higher is arbitrated first. You can describe only one of the visibility or priority.
+For the Z order (zorder), the higher one will be on the front of the screen. You can define values absolutely by number or define relatively to other areas by expressions. You can use comparison operators (> and <), equality operator (=) and That-of operator for the expressions.
+
+- Description example of value :
+Visibility of SampleArea2 is 10, zorder is 5.
+```shell
+Area SampleArea2 {
+	visibility: 10
+	zorder: 5
+}
+```
+- Description example of comparison operator:
+Priority of SampleArea1 is greater than SampleArea2. Zorder of SampleArea1 is less than SampleArea3.
+```shell
+Area SampleArea1 {
+	priority: > That-of SampleArea1
+	zorder: < That-of SampleArea3
+}
+```
+- Description example of range:
+Visibility of SampleArea1 is greater than 1 and less than SampleArea2. Zorder of SampleArea1 is greater than SampleArea3 and less than SampleArea4.
+```shell
+Area SampleArea1 {
+	visibility: (> 1 AND < That-of SampleArea2)
+	zorder: (> That-of SampleArea3 AND < That-of SampleArea4)
+}
+```
+
+- Description example of equality operator:
+```shell
+Area SampleArea1 {
+	visibility: = That-of SampleArea2
+	zorder: = That-of SampleArea3 + That-of SampleArea2
+}
+```
+
+- Equality operator can be omitted.
+```shell
+Area SampleArea1 {
+	visibility: That-of SampleArea2
+	zorder: That-of SampleArea3 + That-of SampleArea2
+}
+```
+
+### 5. ViewContent definition
+
+#### 5.1 ViewContent
+
+ViewContent is an object to be displayed in the Area. ViewContent has multiple states. When ViewContent is allocated to an Area, active state of theViewContent is displayed. Define the Area which can display ViewContent to the ViewContent. You can define several Areas.
+
+Syntax:
+```shell
+ViewContent [ID] {
+  description: [String]
+  allocatable: [ [ID of Area] | [ID of Set] ]
+  [ViewContentState]
+  [[Size]|sizeReference: [ID of Size]]
+  loserType: [GOOD_LOSER | DO_NOT_GIVEUP_UNTIL_WIN | NEVER_GIVEUP]
+}
+```
+
+|Syntax element	|	Description|
+| :---              |    :----     |
+|description:	0..1 | Description|
+|allocatable:	0..* |	Displayable Area. Specify the ID of displayable Areas or Sets with comma-separated.If don’t specify allocatable, should specify allocatable in the ViewContentSet that includes this ViewContent. |
+| [ViewContentState]	1..* |Define the State of ViewContent.|
+|[Size\|sizeReference:]	1..*|Size: Size definition|
+||sizeReference: Reference to Size definition.|
+||※One or more definitions of either Size or sizeReference are needed. Multiple definitions should be defined consecutively.|
+|loserType:	0..1| Action on lost. Specify whether to cancel a request, if ViewContent is not displayed after arbitration. See "Types of Action on lost" for details. If not defined, consider it as "NEVER_GIVEUP".|
+
+Types of Action on lost
+
+|loserType |	Description|
+| :---              |    :----     |
+|GOOD_LOSER	|When losing arbitration, cancel a request.|
+|DO_NOT_GIVEUP_UNTIL_WIN |When the state is changed visible to invisible , cancel a request.|
+|NEVER_GIVEUP|Keep a request.|
+
+Description example:
+```shell
+ViewContent Power {
+description: " Warning from power management"
+  allocatable: [
+    MessageArea, HUDMessageArea
+  ]
+  State Warning {
+    priority: > That-of Power.Attention
+  }
+  State Attention {
+    priority: > That-of TEL.Incoming
+  }
+Size Default {
+description: "Default size"
+width: 200
+height: 200
+}
+  sizeReference: InterruptMessageSize
+  loserType: GOOD_LOSER
+}
+```
+#### 5.2 State(ViewContent)
+
+State is the state of the ViewContent.
+
+Syntax:
+```shell
+State [ID] {
+  description: [String]
+  [priority|value]: [Number|Expression]
+}
+```
+
+|Syntax element	|	Description|
+| :---              |    :----     |
+|description: 	0..1 |	Description
+|[priority\|value]:	1 |	Priority of ViewContent. |
+||Describe the relative value for other State under ViewContent as an expression, or set a numerical value. |
+||The following predefined value can be set as a String.NONE_VALUE, STANDARD_VALUE, MIN_VALUE, MAX_VALUE See "Priority definition"for details. |
+
+Description example:
+```shell
+State Warning {
+  description: "Display warning message"
+priority: > That-of Attention
+}
+State Attention {
+  description: " Display attention message "
+priority: > That-of TEL.Incoming
+}
+```
+### 6. Priority definition
+
+Define the priority of Content to the State under ViewContent or SoundContent (hereinafter, Content). The priority is used when the area / zone arbitration policy is "Priority and First Come First Arbitration" or "Priority and Last Come First Arbitration", the higher one is allocated first. Values can be defined absolutely by number or relative to other areas by expressions. You can describe only one of the visibility or priority. You can use comparison operators (> and <), equality operator (=) and That-of operator for the expressions.
+
+- Description example of value:
+Priority of Warning is 10.
+```shell
+State Warning {
+  description: " Display warning message "
+priority: 10
+}
+```
+- Description example of comparison operator:
+Value of Warning is greater than Attention.
+<br>Value of Attention is greater than State Incoming of TEL of other Content.
+<br>Value of Notice is less than Attention.
+<br>※When referring to the State of another Content, refer to the Content ID and State ID by connecting with “.”.
+```shell
+State Warning {
+  value: > That-of Attention
+}
+
+State Attention {
+  value: > That-of TEL.Incoming
+}
+
+State Notice {
+  value: < That-of Attention
+}
+```
+
+- Description example of range: Priority of Attention is greater than Incoming of TEL and less than Warning.
+<br>※When referring to the State of another Content, refer to the Content ID and State ID by connecting with “.”.
+```shell
+State Attention {
+  priority: (> That-of TEL.Incoming AND < That-of Warning)
+}
+```
+
+- Description example of equality operator:Value of Attention is equal to State Incoming of TEL of other Content.
+```shell
+State Attention {
+  priority: = That-of TEL.Incoming
+}
+```
+- Equality operator can be omitted.
+```shell
+State Attention {
+  priority: That-of TEL.Incoming
+}
+```
+
+### 7. Screen layout definition
+
+#### 7.1. Display
+
+Display represents one screen. When defined more than one, it will be Multi-screen layout.
+The Display defines the set of Areas to be allocated on the screen.
+
+Syntax:
+```shell
+Display [ID] {
+  description: [String]
+  [CompositeArea]
+  [[Size]|sizeReference:[ID of Size]]
+}
+```
+
+|Syntax element	|	Description|
+| :---              |    :----     |
+| description: 	0..1 |	Description|
+|[CompositeArea]	1 |	Component of the screen|
+|[Size\|sizeReference:]	1 |	Size: Size definition|
+|| sizeReference: Reference to Size definition|
+|| ※One or more definitions of either Size or sizeReference are needed. |
+
+Description example:
+```shell
+Display METER {
+	description:"Meter display definition"
+	Size FULLSCREEN {
+		width: 500
+		height: 400
+	}
+	CompositeArea METER_Root {
+		layout: FixedPositionLayout {
+			PositionContainer {
+				x: 100
+				y: 100
+				basePoint: LEFT_TOP
+				areaReference: SpeedMeterArea
+			}
+		}
+	}
+}
+```
+
+#### 7.2. CompositeArea
+
+CompositeArea specifies an Area that becomes a component of Display.
+
+Syntax:
+```shell
+CompositeArea [ID] {
+  description: [String]
+  layout: [FixedPositionLayout]
+}
+```
+
+|Syntax element	|	Description|
+| :---              |    :----     |
+|description: 	0..1 |	Description |
+|layout: [FixedPositionLayout]	1|	Layout type of Area|
+
+Description example:
+```shell
+CompositeArea METER_Root {
+	description:" Definition of Area’s layout method"
+	layout: FixedPositionLayout {
+		PositionContainer {
+			x: 100
+			y: 100
+			basePoint: LEFT_TOP
+			areaReference: SpeedMeterArea
+		}
+	}
+}
+```
+
+#### 7.3. FixedPositionLayout
+
+FixedPositionLayout declares that areas are laid out with fixed values. The specific position define by PositionContainer.
+
+Syntax:
+```shell
+FixedPositionLayout {
+  [PositionContainer]
+}
+```
+
+|Syntax element	|	Description|
+| :---              |    :----     |
+|[PositionContainer]	1..*|	Position information.|
+
+```shell
+FixedPositionLayout {
+	PositionContainer {
+		x: 100
+		y: 100
+		basePoint: LEFT_TOP
+		areaReference: SpeedMeterArea
+	}
+}
+```
+#### 7.4. PositionContainer
+
+PositionContainer specifies the display position of the Area.
+
+syntax:
+```shell
+PositionContainer {
+  x: [Number]
+  y: [Number]
+  basePoint: [Value]
+  areaReference: [ID of Area]
+  [Offset]
+}
+```
+
+|Syntax element	|	Description|
+| :---              |    :----     |
+|x:	1	|x position|
+|y:	1	|y position|
+|basePoint:	1 |	Defined x, y position. The following predefined value can be set.|
+|| CENTER_BOTTOM (Define x, y as the lower center position)|
+|| CENTER_MIDDLE(Define x, y as center position)|
+|| CENTER_TOP (Define x, y as the upper center position)|
+||LEFT_BOTTOM (Define x, y as the lower left position)|
+||LEFT_MIDDLE (Define x, y as the left center position)|
+||LEFT_TOP (Define x, y as the upper left position)|
+||RIGHT_BOTTOM (Define x, y as the lower right position)|
+||RIGHT_MIDDLE (Define x, y as right center position)|
+||RIGHT_TOP (Define x, y as the upper right position)|
+|areaReference:	1|	Area to be placed in Display. Specify ID of the Area.|
+|[Offset]	0..*|	Display position offset of AreaSpecify the position of the Area for each size.|
+
+
+Description example:
+```shell
+FixedPositionLayout {
+	PositionContainer {
+		x: 100
+		y: 100
+		basePoint: LEFT_TOP
+		areaReference: SpeedMeterArea
+		Offset { x:-50 y:20 sizeReference: SpeedMeterArea }
+	}
+}
+```
+#### 7.5. Offset
+
+Offset is the offset position for each size.
+
+Syntax:
+```shell
+Offset {
+  description: [String]
+  x: [Number]
+  y: [Number]
+  sizeReference: [ID of Size]
+}
+```
+
+|Syntax element	     |	Description|
+| :---             |    :----     |
+|description: 	0..1|	Description|
+|x:	1|	Offset from x position of PositionContainer.|
+|y:	1|	Offset from y position of PositionContainer.|
+|sizeReference:	1|	Size to apply the offset. Specify ID of Size.|
+||※ This Size must be specified in Area.|
+
+Description example:
+```shell
+Offset {
+description:"Offset"
+	x: 100
+	y: -50
+	sizeReference: SpeedMeterSize
+}
+```
+
+### 8. Constraint defination
+
+Constraints can be defined according to the state of the Area/Zone and the state of the ViewContent/SoundContent. The syntax can be used for Constraints is shown below.
+
+- State reference of Area:
+
+|Name	| Notation	|Meaning|
+| :---              |    :----     |    :----     |
+|IsDisplayed | <Area\>.isDisplayed()|	The Area is displayed. (At this time, the ViewContent is necessarily allocated to the Area) True if the Area is displayed.|
+|DisplayingContent| 	<Area\>.displayingContent()|	ViewContent which is displayed in the Area. When the Area is hidden or ViewContent is not allocated, it is not evaluated.
+|AllocatedContent|	<Area\>.allocatedContent()|	ViewContent which is allocated to the Area. Even if the Area is hidden after allocation, it is possible to refer to the allocated ViewContent.|
+|IsHidden|	<Area\>.isHidden()	|The Area is hidden. Regardless of whether the ViewContent is allocated to the Area or not,true if the Area is hidden.|
+|ContentValue|	<Area\>.contentValue()|	The value of the ViewContentState allocated to the Area. If ViewContent is not allocated to the Area, it is not evaluated.|
+|ContentsList|	<Area\>.contentsList()|	A set of ViewContent which is allocatable to the Area.|
+|activeContents|	<Area\>.activeContents()	|The set of active content amang the ViewContent which is allocatable to the Area|
+
+- State reference of ViewContent:
+
+|Name	| Notation	|Meaning|
+| :---              |    :----     |    :----     |
+|IsActive|	<ViewContent\>.isActive()|	True if there is a Content request of ViewContent.|
+|IsVisible|	<ViewContent\>.isVisible()|	The ViewContent is displayed. True if the ViewContent is allocated to any Area.|
+|StateValue	|<ViewContent\>.stateValue()	|Priority/value that is defined in active state of the ViewContent. When the ViewContent has no active state, it does not evaluate.|
+|HasComeEarlierThan|	<ViewContentA\>.hasComeEarlierThan(<ViewContentB\>)|	True if the ViewContentA’s request has come earlier than the ViewContentB’s. When the either ViewContent has been not requested, it does not evaluate.|
+|HasComeLaterThan|	<ViewContentA\>.hasComeLaterThan(<ViewContentB\>)	|True if the ViewContentA’s request has come later than the ViewContentB’s. When the either ViewContent has been not requested, it does not evaluate.|
+|Allocatables|	<ViewContent\>.allocatables()|	A set of Areas where the ViewContent can be displayed.|
+
+- Scene reference:
+
+|Name	| Notation	|Meaning|
+| :---              |    :----     |    :----     |
+|IsOn|	<Scene\>.isOn()|	True if the Scene is valid.|
+|Get|	<Scene\>.<Property\>.get()|	Get scene property value.|
+
+- Stereotyope:
+
+|Name	| Notation	|Meaning|
+| :---              |    :----     |    :----     |
+|isTypeOf|	<Model\>.isTypeOf(“<ID of Stereotype\>”)|	Whether or not “<ID of Stereotype\>” is used in the <Model\> |
+|||It can be applied to the following models Area,ViewContent|
+
+- Operator:
+
+|Name	| Notation	|Meaning|
+| :---              |    :----     |    :----     |
+|AND|	<Bool expression\> AND <Bool expression\>|	True if all Bool expressions are true.|
+|OR|	<Bool expression\> OR <Bool expression\>	|True if any Bool expression is true.|
+|Negation|	! <Bool expression\>|	True if Bool expression is false.|
+|Implication|	<Bool expression\> -> <Bool expression\>	| A -> B is equivalent to ((A AND B) OR !A).|
+|Equal sign (Comparison of values)|	<Expression\> = <Expression\>|	True if the values shown on the left-hand side and the right-hand side are identical.The type of left-hand side and the right-hand side expressions must match.|
+|Equal sign (Comparison of objects)	|<Expression\> == <Expression\>|	True if the values shown on the left-hand side and the right-hand side are identical.The type of left-hand side and the right-hand side expressions must match.|
+|Comparison (greater than)	|<Number\> \> <Number\>|True if the Number on the left-hand side is greater than the Number on the right-hand side.|
+|Comparison (greater than)|	<Number\> \>= <Number\>|True if the Number on the left-hand side is greater than equal to the Number on the right-hand side.|
+|Comparison (less than)|	<Number\> < <Number\>|	True if the Number on the left-hand side is less than the Number on the right-hand side.|
+|Comparison (less than)|	<Number\> <= <Number\>|	True if the Number on the left-hand side is less than the equal to Number on the right-hand side.|
+
+- Quantization symbol:
+
+|Name	| Notation	|Meaning|
+| :---              |    :----     |    :----     |
+|∀(For All)	|For-All<Set\>{ <x\> \| <Expression\> }	|<Set\> contains the ViewContentSet or the SoundContentSet, the AreaSet, the ZoneSet, and the One-time Set. True if <Expression\> is true for all set element <x\>.|
+|∃(Exists)|	Exists< Set\>{ <x\> \| <Expression\> }	|<Set\> contains the ViewContentSet or the SoundContentSet, the AreaSet, the ZoneSet, and the One-time Set. True if < Set\> has one or more elements that satisfy <Expression\>.|
+
+- Built-in defined Expression:
+
+|Name	| Notation	|Meaning|
+| :---              |    :----     |    :----     |
+|All Area|	ALL_AREAS|	A set of all the Areas defined in the Model.|
+|All ViewContent|	ALL_VIEWCONTENTS|	A set of all the ViewContents defined in the Model.|
+|IF-THEN-ELSE Syntax|	IF (<Bool expression\>)THEN <Expression\>ELSE <Expression\>|	The type of the expression must be identical, for the THEN clause, if the Bool expression is true, for THEN and ELSE clause ,if the Bool expression is false.|
+|Let　Expression|	let <Variable name\> = <Object expression\>|	Evaluate <Object expression\>　as variable <variabl name>, which can then be referenced in subsequent expressions|
+|||Can only be used inside the expression. For-All, Exists, Max, Min, Select|
+|Pre-arbitration value specifier|	(pre)<Area \| ViewContent \| Scene\| Scene.Property\> |	Refere to the state before arbitration of Area, ViewContent, Property.|
+
+**The syntax precedence and associativity are shown below:**
+
+|Priority|	Name|	Notation|	Connectivity|
+| :---              |    :----     |    :----     | :----     |
+|1	|Parentheses|	(<Expression\>)	|-|
+|2|	∃(Exists)|	Exists<Set\>{ <x\> \| <Expression\> }|-|
+||	∀(For All)|	For-All<Set\>{ <x\> \| <Expression\> }|	-|
+||	IF-THEN-ELSE Syntax|	IF (<Bool expressinon\>) THEN <Expressinon\> ELSE <Expressinon\>|	-|
+||SetOf operator|	{ <Expression\>, <Expression\> }|	-|
+||	Pre-arbitration value specifier|	(pre)<Area\| ViewContent\| Scene\| Scene.Property\>|	-|
+|3|Predicate connector	|<Object\>.<Predicate expression\>|	Left|
+|4	|Negation|	! <Bool expression\>|	Right|
+|5|	Comparison (less than)|	<Number\> < <Number\>|	Left|
+||	Comparison (greater than)|<Number\> \> <Number\>|Left|
+||	Comparison (less than)|	<Number\> <= <Number\>|	Left|
+||	Comparison (greater than)|	<Number\> \>= <Number\>|	Left|
+|6|	Equal sign (Comparison of values)|	<Expressinon\> = <Expressinon\>|	Left|
+||	Equal sign (Comparison of objects)|	<Expressinon\> == <Expressinon\>|	Left|
+|7|	AND|	<BoolExpressinon\> AND <BoolExpressinon\>	|Left|
+|8	|OR|	<BoolExpressinon\> OR <BoolExpressinon\>|	Left|
+|9	|Implication|	<BoolExpressinon\> -\> <BoolExpressinon\>|	Left|
+
+
+#### 8.1 Constraint
+
+Constraint describes constraint expressions. There are two types of constraint expressions Runtime constraints and Offline constraints. A Runtime constraint is a constraint expression that should be be true at the time of arbitration and controls the behavior of arbitration. An Offline constraint is a constraint expression that should be satisfied after arbitration and tests the arbitration result.
+
+Syntax:
+```shell
+Constraint [ID] {
+  description: [String]
+  runtime: [true|false]
+  [expression]
+}
+```
+
+|Syntax element		|Description|
+| :---              |    :----     |
+|description: 	0..1|	Description|
+|runtime: 	1	|true: Runtime constraint|
+||Arbitrate each Area / Zone to be true this constraint.|
+||false: Offline constraint|
+||Verify that this constraint is true after all Area arbitration.|
+|[expression]	1|	Constraint expression|
+
+Description example
+
+- AND/ OR/ Negation
+<br>In the constraint expression, it is possible to express logical AND, logical OR, negation, which is a general logical operator, with AND, OR, and !. By using () you can also use in combination.
+
+Example: Content1 is displayed or Content2 and Content3 are not displayed at the same time.
+```shell
+Constraint SampleConstraint1 {
+runtime: true
+Content1.isVisible() OR !(Content2.isVisible() AND Content3.isVisible())
+}
+```
+Example: SampleContent1 is displayed or SampleContent2 is not displayed.
+```shell
+Constraint SampleConstraint1 {
+	description: "Sample Constraint Expression"
+	runtime: true
+	SampleContent1.isVisible() OR !SampleContent2.isVisible()
+}
+```
+
+- Implication
+
+Implications are false only if the left-hand side is true and the right-hand side is false, otherwise it is true.
+
+Example: SampleContent4 is displayed if there is a request of SampleContent4.
+```shell
+Constraint SampleConstraint3 {
+	runtime: true
+	SampleContent4.isActive() -> SampleContent4.isVisible()
+}
+```
+
+Example: If SampleArea1 displays SampleContent3, SampleArea2 does not display SampleContent3.
+```shell
+Constraint SampleConstraint2 {
+	runtime: true
+	(SampleArea1.displayingContent() == SampleContent3)
+-> !(SampleArea2.displayingContent() == SampleContent3)
+}
+```
+
+Example: If the value of the content displayed on SampleArea1 is higher than the value of the content displayed in SampleArea2, hide SampleArea2.
+```shell
+Constraint SampleConstraint2 {
+	runtime: true
+	(SampleArea1.contentValue() > SampleArea2.contentValue())
+-> SampleArea2.isHidden())
+}
+```
+
+Example: If the value of property1 of the information received from other RBAModel (Project) is 1, Content10 is not displayed.
+```shell
+Constraint SampleConstraint {
+  (SampleScene1.isOn() AND SampleScene1.property1.get() = 1)
+    -> ! Content10.isVisible()
+}
+```
+
+- For-All
+
+For-All targets a set, and it is true if all element of the set satisfies a lambda expression ({element name declaration | element condition}).
+For the set, you can specify a defined set or an One-time set. (Refer to “Group definition” for more informations.)
+<br>Example: If SampleContent1 is displayed, all Areas of AreaGroup1 is not displayed.
+<br> It is assumed that "AreaGroup1" is defined as AreaSet.
+
+```shell
+Constraint SampleConstraint {
+	runtime: true
+	SampleContent1.isVisible() ->
+For-All AreaGroup1 { x | x.isHidden() }
+}
+```
+
+- Exists
+
+Exists targets a set, and it is true if even one element of the set satisfies a Lambda expression ({element name declaration | element condition}).
+<br>For the set, you can specify a defined set or an One-time set. (Refer to “Group definition” for more informations.)
+<br>Example: If any Content of ContentGroup1 is displayed, all Areas of AreaGroup1 is not displayed.
+<br> It is assumed that "ContentGroup1" is defined as ContentSet.
+<br> It is assumed that "AreaGroup1" is defined as AreaSet.
+```shell
+Constraint SampleConstraint {
+	runtime: true
+	Exists ContentGroup1{ x | x.isVisible() } ->
+For-All AreaGroup1 { x | x.isHidden() }
+}
+```
+
+- IF-THEN-ELSE
+Example: If the scene is SampleScene1, SampleContent4 is displayed, otherwise SampleContent4 is not displayed.
+
+```shell
+Constraint SampleConstraint4 {
+	runtime: true
+	IF(SampleScene1.isOn())
+	THEN
+		SampleContent4.isVisible()
+	ELSE
+		!SampleContent4.isVisible()
+}
+```
+
+- (pre)
+Example: If SampleContent 1 is displayed (before arbitration), SampleContent 2 is not displayed.
+```shell
+Constraint SampleConstraint {
+	runtime: true
+(pre)SampleContent1.isVisible() -> !SampleContent2.isVisible()
+}
+```
+
+- HasComeEarlierThan/HasComeLaterThan
+Example: If request SampleContent 1 has come earlier then SampleContent 2, SampleContent 2 does not displayed.
+```shell
+Constraint SampleConstraint {
+	runtime: true
+SampleContent1.hasComeEarlierThan(SampleContent2) -> !SampleContent2.isVisible()
+}
+```
+Below constraint behave as same as above.
+```shell
+Constraint SampleConstraint {
+	runtime: true
+SampleContent2.hasComeLaterThan(SampleContent1) -> !SampleContent2.isVisible()
+}
+```
+
+#### 8.2 Syntax sugar
+
+This syntax sugar simplifies the constraint expressions and improves their readability. You can use them like the existing constraint expressions.
+Below are the syntax sugars that can be used.
+
+- Inequality（!=）
+<br>It means that the left side value and the right side value are not equal. You can use this to compare objects.
+True if the left side value and the right side value are not equal.
+The types of expressions on the left and the right sides must match.
+
+|Type|	Operator|
+| :---              |    :----     |
+|Notation|	<Expression1\> != <Expression2\>|
+|ECE*|	!(<Expression1\> == <Expression2\>)|
+
+*ECE: Equivalent constraint expression
+
+Description example: The ViewContent allocated to AreaA is not Content1.
+
+|||
+| :---              |    :----     |
+|Notation|	AreaA.allocatedContent() != Content1|
+|ECE|	!( AreaA.allocatedContent() == Content1)|
+
+- Allocation of Area/Zone
+<br>It indicates that ViewContent/SoundContent is allocated to the Area/Zone.
+True if theViewConten/SoundContentt is allocated to the Area/Zone.
+
+|Type|	State reference of ViewContent|
+| :---              |    :----     |
+|Notation|	<ViewContent\>.isAllocatedTo(<Area\>)|
+|ECE|	<Area\>.allocatedContent() == <ViewContent\>|
+
+Description example: The Content1 is allocated to the AreaA.
+
+|||
+| :---              |    :----     |
+|Notation|	Content1.isAllocatedTo(AreaA)|
+|ECE|	AreaA.allocatedContent() == Content1|
+
+- Allocation changing of Area/Zone
+<br>It indicates a changing of the ViewContent’s/SoundContent’s allocated to the Area/Zone.
+True if the changing happens.
+
+|Type	|State reference of Area|
+| :---              |    :----     |
+|Notation|	<Area\>.isChanged()|
+|ECE|	!((pre)<Area\>.allocatedContent() == <Area\>.allocatedContent())|
+
+Description example: The ViewContent allocated to AreaA has changed.
+
+|||
+| :---              |    :----     |
+|Notation|	AreaA.isChanged()|
+|ECE|	!((pre)AreaA.allocatedContent() == AreaA.allocatedContent())|
+
+- Changing of a content allocated to Area/Zone
+<br>It indicates whether a ViewContent/SoundContent allocated to the Area/Zone has changed to the specified ViewContent/SoundContent.True if the changing happens
+
+|Type	|State reference of Area|
+| :---              |    :----     |
+|Notation|	<Area\>.isTranslatedTo(<ViewContent\>)|
+|ECE|	!((pre)<Area\>.allocatedContent() == <ViewContent\>) AND (<Area\>.allocatedContent() == <ViewContent\>)|
+
+Description example: A ViewContent allocated to the AreaA has changed to Content1.
+
+|||
+| :---              |    :----     |
+|Notation|	AreaA.isTranslatedTo(Content1)|
+|ECE	|!((pre)AreaA.allocatedContent() == Content1) AND (AreaA.allocatedContent() == Content1)|
+
+- Displaying in the Area
+<br>It indicates whether the ViewContent displayed or not in the Area.
+True if the ViewContent is displayed in the Area.
+
+|Type|	State reference of ViewContent|
+| :---              |    :----     |
+|Notation|	<ViewContent\>.isDisplayedOn(<Area\>)|
+|ECE|	<Area\>.isDisplayed() AND (<Area\>.displayingContent() == <ViewContent\>)|
+
+Description example: The Content1 is displayed in the AreaA.
+
+|||
+| :---              |    :----     |
+|Notation|	Content1.isDisplayedOn(AreaA)|
+|ECE|	AreaA.isDisplayed() AND (AreaA.displayingContent() == Content1)|
+
+- Display changing of the Area
+<br>It indicates whether the display of the Area changes or not.
+True if the change happens.
+
+|Type	|State reference of Area|
+| :---              |    :----     |
+|Notation|	<Area\>.isChangedDisplay()|
+|ECE	|!((pre)<Area\>.displayingContent() == <Area\>.displayingContent()) OR ((pre)<Area\>.isDisplayed() AND !<Area\>.isDisplayed()) OR (!(pre)<Area\>.isDisplayed() AND <Area\>.isDisplayed())|
+
+Description example: The display of the AreaA has changed.
+
+|||
+| :---              |    :----     |
+|Notation	|AreaA.isChangedDisplay()|
+|ECE	|!((pre)AreaA.displayingContent() == AreaA.displayingContent()) OR((pre)AreaA.isDisplayed() AND !AreaA.isDisplayed()) OR(!(pre)AreaA.isDisplayed() AND AreaA.isDisplayed())|
+
+- Changing of the displayed ViewContent to the specified ViewContent
+<br>It indicates whether the ViewContent displayed in the Area has changed to anther specified ViewContent.
+True if the change happens.
+
+|Type	|State reference of Area|
+| :---              |    :----     |
+|Notation|	<Area\>.isTranslatedViewTo(<ViewContent\>)|
+|ECE	|(<Area\>.isDisplayed()) AND (<Area\>.displayingContent() == <ViewContent\>) AND (!((pre)<Area\>.displayingContent() == <ViewContent\>) OR !(pre) <Area\>.isDisplayed())|
+
+Description example: A ViewContent displayed in the AreaA has changed to another Content1.
+
+|||
+| :---              |    :----     |
+|Notation|	AreaA.isTranslatedViewTo(Content1)|
+|ECE|	(AreaA.isDisplayed()) AND (AreaA.displayingContent() == Content1) AND (!((pre)AreaA.displayingContent() == Content1) OR !(pre)AreaA.isDisplayed())|
+
+- Hide a lower priority Area
+<br>Compare the two Areas and hide the Area displaying a ViewContent with lower priority.
+
+|Type|	State reference of Area|
+| :---              |    :----     |
+|Notation|	HideLowerPriority(<Area1\>, <Area2\>)|
+|ECE|	((<Area1\>.contentValue() < <Area2\>.contentValue() -\> <Area1\>.isHidden()) AND (<Area1\>.contentValue() \> <Area2\>.contentValue() -\> <Area2\>.isHidden()))|
+
+Description example: AreaA and AreaB are compared to hide the Area which displays a ViewContent with lower priority.
+
+|||
+| :---              |    :----     |
+|Notation|	HideLowerPriority(AreaA, AreaB)|
+|ECE|	((AreaA.contentValue() < AreaB.contentValue() -\> AreaA.isHidden()) AND (AreaA.contentValue() \> AreaB.contentValue() -\> AreaB.isHidden()))|
+
+### 9. Group definition
+
+#### 9.1 AreaSet
+
+When dealing with multiple Areas in the Constraint expression, in order to describe it simply, you can define multiple Areas together in one group.
+
+Syntax:
+```shell
+AreaSet [ID] {
+  description: [String]
+  target: [ [ID of Area] ]
+}
+```
+
+|Syntax element	|	Description|
+| :---             |    :----     |
+|description: |	0..1	Description|
+|target:	0..*	| Areas or AreaSets which compose the group. Specify the ID of the Area or the AreaSet with comma-separated.|
+
+Description example:
+```shell
+AreaSet MainScreen {
+	description: "Area constituting the main screen"
+	target: [SampleArea, SampleArea1, OtherAreaSet]
+}
+```
+#### 9.2 ViewContentSet
+
+When dealing with multiple ViewContents in the Constraint expression, in order to describe it simply, you can define multiple ViewContents together in one group.
+
+Syntax:
+```shell
+ViewContentSet [ID] {
+  description: [String]
+  allocatable: [ [ID of Area] ]
+  target: [ [ID of ViewContent] ]
+}
+```
+
+|Syntax element	|	Description|
+| :---             |    :----     |
+|description: |	0..1	Description|
+|allocatable:	0..*|	Displayable Areas or AreaSets.Specify the ID of the Areas or the AreaSets with comma-separated.|
+|target:	0..*|	ViewContents or ViewContentSets which compose the group. Specify the ID of the ViewContents or ViewContentSets with comma-separated.|
+
+Description example:
+```shell
+ViewContentSet InterruptContent{
+  allocatable: [
+    MessageArea, HUDMessageArea, InterruptAreaGroup
+  ]
+  target: [
+    TEL,Power, ViewContentGroup
+  ]
+}
+```
+
+#### 9.3 One-time Set
+
+Specify an set in the For-All or the Exists constraint, you can define the One-time set.
+
+Syntax:
+```shell
+{ [ID] }
+```
+
+|Syntax element	|	Description|
+| :---             |    :----     |
+|[ID]	1..*	|Element of the set. Specify the IDs of elements with comma-separated.
+||The type of elements should be same.|
+||At this time, Area and AreaSet regard it as the same type.( ViewContent and ViewContentSet are treat similarly.)
+
+- Description example: Define the One-time set as AreaSet.
+```shell
+Constraint SampleConstraint {
+	runtime: true
+	SampleContent1.isVisible() ->
+For-All {Area1, Area2, Area3} { x | x.isHidden() }
+}
+```
+
+- Description example: Define the One-time set as ViewContentSet.
+```shell
+Constraint SampleConstraint {
+	runtime: true
+	Exists {ViewContent1, ViewContentSet1} { x | x.isActive() -> x.isVisible() }
+}
+```
+### 10. Scene definition
+#### 10.1 Scene
+Scene comprehensively expresses the state at the time including the system, and it is used to switch the status of Area/Zone, View/Sound Content by Scene. You can also define the Global scene and share the results of arbitration among multiple RBA Models (Projects).
+
+Syntax:
+```shell
+Scene [ID] {
+  description: [String]
+  global: [true|false]
+  [Property]
+}
+```
+
+|Syntax element	|	Description|
+| :---             |    :----     |
+|description: 	0..1|	Description|
+|global: 	0..1|	true: Global Scene for sharing arbitration results with other RBA Models (Projects).|
+||false: Local Scene.|
+||If not defined, consider it as "false".|
+|[Property]	0..*|	Information for sharing arbitration results with other RBA models (Projects).|
+||Can define only if global is true.|
+
+Description example:
+```shell
+Scene AutoDrivingScene {
+  description: "In auto driving mode"
+}
+
+Scene DisplayEventNotification {
+  global: true
+  int OverallPriority: 6
+  int RiskSeverity: 3
+  int RiskMargin: 1
+}
+```
+#### 10.2 Property
+
+Property is arbitrary properties which is defined in the Scene.
+
+Syntax:
+```shell
+int [String]: [Number]
+```
+
+|Syntax element	|	Description|
+| :---             |    :----     |
+|[String]	1	|Arbitrary Property name|
+|[Number]	1	|Default value of Property. Positive integer can be specified.|
+
+Description example:
+```shell
+int RiskSeverity: 3
+```
+
+### 11. Stereotype
+
+Syntax:
+```shell
+StereoType<[Target Model Name]> [ID] ([valiable]) @BEGIN@
+description: [String]
+    [Propaties of Element]
+@END@
+```
+
+|Syntax element	|	Description|
+| :---              |    :----     |
+|description: 	0..1|	Description|
+|[Target Model Name]	1|	Identify the applicable model by describing the model element keywords|
+||It can be applied to the Area, ViewContent models|
+|[valiable]	0..*|	Describe an arbitrary variable as the parameter to be replaced, which will be set in the property of the model element specified in [Target Model Name].If there are multiple variables, separate them with commas.|
+|[Properties of Element]	1..*|	Describe the properties of the model element specified in [Target Model Name].In the property, the value to be replaced is written in @{[variable]} .|
+||The variables must match the variables described in ().|
+
+Description example:
+```shell
+Stereotype<ViewContent> display_warnning (name,allocatable,priority) @BEGIN@
+    description: “@{name}”
+    allocatable: [@{allocatable}]
+    Size WarnSize {
+        width: 300
+        height: 100
+    }
+    State NORMAL { piority: @{priority} }
+
+@END@
+```
+
+### 12. Tag
+
+Syntax:
+```shell
+<<[Stereotype ID]>> | <<[Stereotype ID]>>{“[String]”}
+```
+
+|Syntax element	|	Description|
+| :---              |    :----     |
+|[ID of Stereotype]	0..*|	Can be assigned to Area, ViewContent|
+||If StereoType is defined, then the child elements and attributes defined there will be expanded as child elements and attributes of this object|
+||Multiple definitions can be made for a single model. To define more than one, define them consecutively.|
+|[String]	0..*	|Argument value|
+||If there is no argument, it can be omitted|
+
+Description example:
+```shell
+ViewContent Warning_1 {
+    <<display_warning>>{ “Warning_01”,”Area1”,“1” }
+}
+
+ViewContent Warning_2 {
+    <<display_warning>>{ “Warning_02”,”Area2”,”2” }
+}
+
+Stereotype<ViewContent> display_warnning (name,allocatable,priority) @BEGIN@
+    description: “@{name}”
+    allocatable: [@{allocatable}]
+    Size WarnSize {
+        width: 300
+        height: 100
+    }
+    State NORMAL { piority: @{priority} }
+@END@
+```
+
+## Generate .json from .rba file
+Download [prebuilt package](https://git.automotivelinux.org/staging/rba-tool/tree/tool_bin)
+
+- If some errors occur, RBAModel.json is not generated (exit code 1).
+````
+java -cp ./ -jar JSONGenerator.jar "[path to model directory]" "[path to output directory]"
+````
+
+Example:
+
+- RBAModel.json file is generated in directory same as JSONGenerator.jar
+````
+java -cp ./ -jar JSONGenerator.jar "./RBAModel.rba"
+````
+
+- RBAModel.json file is generated in ~/ directory
+````
+java -cp ./ -jar JSONGenerator.jar "./RBAModel.rba" "~/"
+````
+Note: For the reference .rba file is given under the path [prebuilt package/sample_model](https://git.automotivelinux.org/staging/rba-tool/tree/tool_bin/sample_model)
diff --git a/docs/05_Component_Documentation/05_drm_lease_manager.md b/docs/05_Component_Documentation/05_drm_lease_manager.md
new file mode 100644
index 0000000..3b7b2e9
--- /dev/null
+++ b/docs/05_Component_Documentation/05_drm_lease_manager.md
@@ -0,0 +1,108 @@
+---
+title: DRM lease manager
+---
+
+# DRM Lease Manager
+
+## Overview
+
+The DRM Lease Manager is used in AGL to allocate display controller outputs to different processes. Each process has direct access to its allocated output via the kernel DRM interface, and is prevented from accessing any other outputs managed by the display controller.
+
+The display controller partitioning is made possible by using the kernel DRM Lease feature.  For more information on the DRM lease functionality, please see the Linux kernel [DRM userspace API documentation](https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html).
+
+
+## Usage
+
+### Building DRM Lease manager and sample clients
+
+Enable the  `agl-drm-lease` AGL feature when setting up your build environment
+with aglsetup.sh.
+
+This will add the drm-lease-manager package to the image, and will add DRM
+lease support to the following packages:
+
+* weston
+* kmscube
+
+kmscube is not included in the image by default. To add the package to the
+image, add the following to your local.conf
+
+```
+IMAGE_INSTALL_append = " kmscube"
+```
+
+### Starting the DRM lease manager
+
+The drm-lease-manager must be the only process to directly open the DRM device.
+Shut down any running window systems (eg. weston or agl-compositor) and run:
+
+```shell
+  systemctl start drm-lease-manager
+```
+
+This will create a lease for each output connection on the platform.
+The name of each lease will be in the form of `card0-<output name>`
+ (eg. `card0-LVDS-1` or `card0-HDMI-A-1`)
+
+**Note**: `drm-lease-manager` can be started on a different display controller (i.e. not `card0`) by modifying the command line in the systemd unit file.
+
+Run the help command for details.
+
+```shell
+  drm-lease-manager --help
+```
+
+### Running weston
+
+weston can be started on any available DRM lease by running with the
+`--drm-lease=<lease name>` option.
+
+```shell
+  weston --drm-lease=card0-HDMI-A-1
+```
+
+### Running kmscube sample
+With the `drm-lease-manager` running, `kmscube` can display on any available
+lease by launching it with the `-L -D<lease name>` options.
+
+```shell
+  kmscube -L -Dcard0-HDMI-A-1
+```
+
+Multiple weston or kmscube instances (one per DRM lease) can be started at the same time.
+
+## Adding support to your application
+
+The DRM Lease Manager packages includes a client library (libdlmclient) to request access to the DRM leases it creates.  The client library provides file descriptors that can be used as if they were created by directly opening the underlying DRM device.
+
+Clients that want _direct access_ to the DRM device can use this library to do so.  Compositor (agl-compositor or weston) client applications do not need to use this interface.  
+
+
+To use the DRM leases, clients only need to replace their calls to
+`drmOpen()` and `drmClose()` with the appropriate libdlmclient API calls.
+
+### libdlmclient API usage
+
+_Error handling has been omitted for brevity and clarity of examples._
+
+#### Requesting a lease from the DRM Lease Manager
+
+```c
+  struct dlm_lease *lease = dlm_get_lease("card0-HDMI-A-1");
+  int drm_device_fd = dlm_lease_fd(lease);
+```
+
+`drm_device_fd` can now be used to access the DRM device
+
+#### Releasing a lease
+
+```c
+  dlm_release_lease(lease);
+```
+
+**Note: `drm_device_fd` is not usable after calling `dlm_release_lease()`**
+
+## Runtime directory
+A runtime directory under `/var` is used to keep the Unix Domain sockets that the drm-lease-manager and clients to communicate with each other.
+
+The default path is `/var/run/drm-lease-manager`, but can be changed by setting the `DLM_RUNTIME_PATH` environment variable.
diff --git a/docs/05_Component_Documentation/07_pipewire_wireplumber.md b/docs/05_Component_Documentation/07_pipewire_wireplumber.md
new file mode 100644
index 0000000..e58b97d
--- /dev/null
+++ b/docs/05_Component_Documentation/07_pipewire_wireplumber.md
@@ -0,0 +1,159 @@
+---
+title: PipeWire / WirePlumber
+---
+
+# PipeWire / WirePlumber
+
+## Overview
+
+AGL uses the PipeWire daemon service to provide audio playback and capture capabilities.
+PipeWire is accompanied by a secondary service, WirePlumber (also referred to as the
+*session manager*), which provides policy management, device discovery, configuration and more.
+
+Applications can connect to the PipeWire service through its UNIX socket, by using either the
+*libpipewire* or *libwireplumber* libraries as a front-end to that socket.
+
+Upstream documentation for these components can be found at the links below:
+
+- [PipeWire documentation](https://docs.pipewire.org/)
+
+- [WirePlumber documentation](https://pipewire.pages.freedesktop.org/wireplumber/) 
+
+- [PipeWire Wiki](https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home)
+
+## APIs
+
+### libpipewire
+
+The main entry point for applications to access the audio system is the API offered by
+*libpipewire*. The functionality offered by *libpipewire* is vast and it is beyond the
+scope of this document to describe it all.
+
+For playback and capture, applications should use *struct pw_stream* and its associated methods. 
+See [PipeWire: Tutorial - Part 4: Playing a tone](https://docs.pipewire.org/page_tutorial4.html)
+for a starting point.
+
+### GStreamer (Recommended)
+
+For convenience, applications that use GStreamer can use the PipeWire GStreamer elements to 
+plug the functionality offered by *struct pw_stream* directly in the GStreamer pipeline. These 
+elements are called *pipewiresrc* and *pipewiresink*
+
+Example:
+
+```shell
+> gst-launch-1.0 audiotestsrc ! pipewiresink
+```
+
+Through these elements, it is possible to specify the application role by setting it in the
+*stream-properties* property of the element, as shown below:
+
+```shell
+> gst-launch-1.0 audiotestsrc ! pipewiresink stream-properties="p,media.role=Multimedia""
+```
+
+or, in the C API:
+
+```c
+gst_util_set_object_arg (sink, "stream-properties", "p,media.role=Multimedia");
+```
+
+Of course, it is also possible to use *alsasink* and *alsasrc* and route audio through the
+virtual ALSA device that is mentioned below. This is also the default behavior of *playbin*
+and similar auto-plugging elements, because the PipeWire GStreamer elements are not autoplugged
+(this may change in a future version).
+
+### ALSA
+
+PipeWire offers a virtual ALSA device (called *pipewire*) that redirects audio to PipeWire
+through an ALSA PCM plugin. This device is the default one, so unless you explicitly specify
+a device in your ALSA client application, audio will go through PipeWire instead.
+
+Example:
+
+```shell
+> aplay sound.wav  # the default device is 'pipewire'
+> aplay -D pipewire sound.wav
+```
+
+In order to specify the application role while using the ALSA compatibility device, pass the role
+as a device parameter like this:
+
+```shell
+> aplay -D pipewire:ROLE=Navigation turnleft.wav
+```
+
+### Audiomixer service
+
+See the separate [agl-service-audiomixer](https://git.automotivelinux.org/apps/agl-service-audiomixer/about/) documentation.
+
+### libwireplumber
+
+The WirePlumber library provides API that wraps libpipewire and makes it easier to work with 
+when you are writing control applications, such as a volume mixer. The audiomixer service is in 
+fact implemented using *libwireplumber*.
+
+WirePlumber also provides support for lua-based scripting. Standalone scripts, executed with the 
+*wpexec* tool, may be used  as a means to rapidly make use of the API provided by *libwireplumber*
+
+## Tools
+
+* **wpctl**: allows inspecting the devices, choosing which source & sink are the default ones 
+  and allows volume/mute adjustments to be made on the command line. Try `wpctl status` and
+  `wpctl help` to get started with it
+
+* **wpexec**: allows running wireplumber lua scripts standalone, which is useful to implement
+  custom scripts to interact with PipeWire
+
+* **pw-cli**: this is the main tool for interacting with pipewire directly
+
+* **pw-dump**: dumps all the objects in the pipewire graph to a big JSON. The output of this
+  tool is very useful to include in bug reports. It is also suitable for implementing scripts
+  that parse information with jq
+
+* **pw-dot** is a useful debug tool that dumps the objects in a dot graph for easy visualization
+
+* **pw-cat / pw-play / pw-record**: This is a set of tools similar to aplay/arecord, for simple
+  audio operations
+
+* **pw-top**: This is a performance measurement tool that shows realtime timing information
+  about the audio pipeline. Before running this tool, you will need to uncomment the loading
+  of "libpipewire-module-profiler" in /etc/pipewire/pipewire.conf and restart pipewire
+
+## Systemd Integration
+
+The PipeWire service, `pipewire.service`, is activated on demand, via systemd socket activation,
+by `pipewire.socket`. The WirePlumber service, `wireplumber.service`, is bound to the pipewire
+service and therefore started and stopped together with the PipeWire service.
+
+If you wish to manually stop or restart both services, you can do so by using *systemctl*,
+operating on the *.socket* unit:
+
+```shell
+> systemctl restart pipewire.socket
+> systemctl stop pipewire.socket
+```
+
+## Debugging
+
+The PipeWire daemon can be configured to be more verbose by editing
+**/etc/pipewire/pipewire.conf** and setting `log.level=n` (n=0-5) in section
+`context.properties`.
+
+Similarly, the WirePlumber daemon can be configured to be more verbose by editing
+**/etc/wireplumber/wireplumber.conf** and setting `log.level=n` (n=0-5) in section
+`context.properties`.
+
+All messages will be available in the systemd journal, inspectable with journalctl.
+
+For applications, at runtime, `PIPEWIRE_DEBUG` can be set to a value between 0 and 5, 
+with 5 being the most verbose and 0 the least verbose.
+
+For applications that use *libwireplumber* the equivalent environment variable is
+`WIREPLUMBER_DEBUG`, which also takes values between 0 and 5.
+
+The default debug level for the daemons is 2, while for applications it's 0
+(with few exceptions).
+
+More information is also available on 
+[WirePlumber's documentation on debug logging](https://pipewire.pages.freedesktop.org/wireplumber/daemon-logging.html)
diff --git a/docs/05_Component_Documentation/08_Instrument_Cluster_Sound_Management.md b/docs/05_Component_Documentation/08_Instrument_Cluster_Sound_Management.md
new file mode 100644
index 0000000..57f6dd2
--- /dev/null
+++ b/docs/05_Component_Documentation/08_Instrument_Cluster_Sound_Management.md
@@ -0,0 +1,124 @@
+---
+title: Instrument Cluster Sound Management
+---
+
+# Instrument Cluster Sound Management
+
+## Introduction
+
+This document describes the design of the software setup which enables the integration
+of AGL’s sound system with applications running in the Instrument Cluster domain.
+This software setup is specific to the case where a single system is used to implement
+both the Instrument Cluster and some other domain of the vehicle, typically the
+In-Vehicle-Infotainment domain, using container technology to separate them.
+
+Applications running in the Instrument Cluster need a way to safely play important
+sounds to alert the driver of conditions that need the driver’s attention. At the same
+time, in a containerized environment that serves multiple vehicle domains, applications
+running in other containers may be using the sound hardware to play less important sounds,
+such as music, which conflicts with the IC’s need to play sound on the same hardware.
+
+The solution developed here, for safety reasons, relies on the operating system and the
+hardware itself to allow the IC applications to stream sounds to the speakers using a
+dedicated device handle, while applications from other domains are all routed through a
+sound server that runs on the host container and operates on a different sound device handle.
+
+However, to achieve good inter-operation, there is need for additional software mechanisms
+that will work in combination with this hardware-based solution. First of all, it is necessary
+to have a mechanism that allows IC applications to pause all sounds that are being routed via
+the sound server while there is an important IC sound playing and resume them afterwards.
+This is so that other domain applications can be informed of this temporary pause and offer
+the appropriate user experience. Secondly, it is desirable to have separation of duties
+between the host and the other domain’s (non-IC) container. It should be the responsibility
+of the other domain’s container to implement the sound system policy, so that the host does
+not need to be aware of the exact applications that are running on this container.
+
+## Requirements
+
+- Single system shared between IC and at least one secondary domain (IVI, other ...)
+
+- The domains are separated using containers
+
+- All the containers, including the host, are running a variant of AGL
+
+- The host OS and the secondary domain container use PipeWire and WirePlumber
+  to implement the sound system
+
+- The sound hardware offers, on the Linux kernel driver side, a separate ALSA
+  device for sounds that belong to the IC and a separate ALSA device for other sounds
+
+## Architectural design
+
+![Architecture overview](images/ic-sound-manager/architecture.png)
+
+The core of the sound system consists of the PipeWire daemon, which is responsible for routing
+audio between the kernel and applications running in the “Other Container”.
+
+The PipeWire session is orchestrated by a secondary daemon, WirePlumber. WirePlumber is
+designed in such a way so that it can have multiple instances, for task separation.
+One instance shall be running in the host container and it shall be responsible for
+managing the devices that PipeWire handles as well as the security isolation between
+different applications and different containers. At least one more instance shall be
+running in the “Other Container” and be responsible for implementing policy mechanisms
+related to the applications that are running in that container.
+
+Further WirePlumber instances are possible to run as well. For instance, it may be desirable
+to have another “policy” instance in a third container that implements another vehicle system
+and shares the main PipeWire daemon from the host. Additionally, the “Other Container” may
+be running a separate WirePlumber instance to manage bluetooth audio devices, which shall be
+the responsibility of that container instead of the host.
+
+To implement communication between the IC and the host, a third daemon is used: pipewire-ic-ipc.
+This daemon listens on a UNIX domain socket for messages from the IC applications and offers
+them the ability to pause or resume sounds that are being routed via PipeWire.
+
+Finally, IC applications are given a library (icipc library) that allows them to send messages
+to pipewire-ic-ipc on the host. This library is minimal and has no external dependencies,
+for safety reasons.
+
+For sound playback, IC applications are expected to use the ALSA API directly and communicate
+with the dedicated ALSA device that is meant for IC sounds. Arbitration of this device between
+different IC applications is out of scope for this document and it is assumed to be a solved
+problem.
+
+### PipeWire-IC-IPC
+
+This component acts as the server-side component for the UNIX socket that is used for
+communication between the IC applications and the host. It is implemented as a pipewire module,
+therefore it needs the `/usr/bin/pipewire` process in order to be launched. Launching happens
+with a special configuration file (`pipewire-ic-ipc.conf`) which instructs this PipeWire process
+to be launched as a client (`core.daemon = false`) and to load only `module-ic-ipc` together
+with `module-protocol-native`. The latter enables communication with the daemon instance of
+PipeWire (`core.daemon = true`), which implements the sound server.
+
+![PipeWire-IC-IPC Processes](images/ic-sound-manager/pipewire-ic-ipc-processes.png)
+
+### icipc library
+
+The IC Application is given a library (‘libicipc’) that implements the client side of
+pipewire-ic-ipc. This library allows sending two commands:
+
+- SUSPEND
+  - Asks WirePlumber (via PipeWire) to cork applications and mute the ALSA device used by PipeWire
+- RESUME
+  - Reverts the effects of SUSPEND
+
+IC Applications are expected to send the SUSPEND command before starting playback of a sound
+to their dedicated ALSA device. The RESUME command should be sent after playback of this IC
+sound has finished.
+
+It should be noted that the RESUME command is also issued automatically when the IC application
+disconnects from the pipewire-ic-ipc UNIX socket.
+
+If multiple IC application issue SUSPEND to the pipewire-ic-ipc server, then only the first
+SUSPEND generates actions for WirePlumber. The rest are counted and the pipewire-ic-ipc
+server expects an equal number of RESUME commands before generating resume actions for
+WirePlumber.
+
+The implementation of the SUSPEND/RESUME mechanism uses PipeWire’s metadata to signal
+WirePlumber. PipeWire-IC-IPC will look for the “default” metadata object in PipeWire’s list
+of objects and will write the “suspend.playback” key with a value of “true” on id 0.
+The metadata change is then notified to all clients. WirePlumber, being a client, gets
+notified of this change and takes actions. All actions are defined in Lua scripts.
+
+![PipeWire-IC-IPC Calls](images/ic-sound-manager/pipewire-ic-ipc-calls.png)
diff --git a/docs/05_Component_Documentation/09_AGL_Demo_Control_Panel.md b/docs/05_Component_Documentation/09_AGL_Demo_Control_Panel.md
new file mode 100644
index 0000000..af42523
--- /dev/null
+++ b/docs/05_Component_Documentation/09_AGL_Demo_Control_Panel.md
@@ -0,0 +1,140 @@
+---
+title: AGL Demo Control Panel
+---
+# AGL Demo Control Panel
+
+## Introduction
+
+This document describes the design and usage of the **AGL Demo Control Panel**, a **Qt5-based** tool that allows you to control and interact with various **Automotive Grade Linux (AGL)** demo applications. The tool uses **Kuksa.val** and **CAN frame messages** to communicate with the target machine that runs the AGL image(s). You can use the tool to perform tasks such as starting and stopping scripts, changing the vehicle speed and engine RPM, adjusting the HVAC settings, and providing Steering Inputs. The tool is designed to **demonstrate** the capabilities and features of AGL in a **user-friendly** and **interactive** way.
+### Application Overview
+
+To use the control panel, you need to connect the main machine that runs the control panel to the target machine that runs the AGL image(s) using a **LAN/ethernet cable**. You also need to configure the IP address of the Kuksa server and set your preferences in the tool’s settings menu.
+
+![Layers_And_Extensions](images/AGL-Demo-Control-Panel/Application-Logic.png)
+## Installation  
+
+  
+
+- _Note_:
+	If errors occur in Debian based/Rasbian OS during installation, follow the steps mentioned below and skip to step 2:
+```bash
+$ nano requirements.txt
+# -> Comment pyqt5 dependency using "#"
+$ sudo apt install python3-pyqt5 python3-qtpy pyqt5-dev-tools python3-pyqt5.qtsvg -y
+```
+
+- Step 1
+```bash
+$ python3 -m venv control-panel
+$ source control-panel/bin/activate
+```
+
+- Step 2
+```bash
+$ pip3 install -r requirements.txt
+$ pyrcc5 assets/res.qrc -o res_rc.py
+```
+## Setup
+
+Before using the  `AGL Demo Control Panel`, we need to make sure to run the Kuksa.val server  and also have our `can0` interface set up (Optional).
+
+### 1. Connect the Machines
+
+First, we need to connect the machines, i.e. the host machine (Running the control panel) and the target machine (running the AGL image) via LAN or a bridged network (QEMU or VM) 
+### 2. CAN interface (WIP)
+
+To set up the CAN interface between the Host system and the target machine(s) we use [cannelloni](https://github.com/mguentner/cannelloni),
+
+1. Create the virtual CAN interface with the command:
+
+	```bash
+	$ sudo ip link add dev can0 type vcan
+	```
+
+2. On both machines, bring the virtual CAN interface online with the command: 
+
+	```bash
+	$ sudo ip link set up can0
+	```
+
+3. Install cannelloni from its [GitHub repository](https://github.com/mguentner/cannelloni) and run cannelloni with the following commands. 
+
+	_Note_: `cannelloni` is available in AGL, just add `IMAGE_INSTALL:append = " cannelloni"`	to your `conf/local.conf`
+
+	Host Machine (Running `AGL Demo Control Panel`)
+	```bash
+	cannelloni -I can0 -R <target-ip> -r 20000 -l 20000
+	```
+	 Target Machine (Running AGL image)
+	```bash
+	cannelloni -I can0 -R <host-ip> -r 20000 -l 20000 -p
+	```
+
+	You should now be able to send and receive CAN messages between the two machines using the vcan interface and cannelloni.
+
+### 3. Configuration for Kuksa-val-server/ Kuksa databroker
+
+Run the `kuksa-val-server`/`databroker` on `0.0.0.0` by either restarting the server, editing `/etc/default/kuksa-databroker` or add the `agl-demo-preload` as a feature to your build of AGL.  The server should be started using the `--address 0.0.0.0` argument.
+
+Now, you can create a custom configuration to save your specific preferences for the settings page by creating the `*.ini*` files in the,
+-  `/etc/agl-demo-control-panel.ini`
+- `$HOME/.local/share/agl-demo-control-panel/config.ini`
+	
+```python
+[default]
+preferred-config=AGL-kuksa-val-server
+
+# [cutom-config-template]
+# ip=<ip address>
+# port=<port number>
+# protocol=<ws|grpc>       # ws/grpc -> kuksa-val-server, grpc -> databroker
+# insecure=<true|false>    
+# cacert=<default|/path/to/CA.pem>
+# token=<default|/path/to/token>      
+# tls_server_name=<name>
+
+[kuksa-val-server]
+ip=localhost
+port=8090
+protocol=ws
+insecure=false
+token=default
+tls_server_name=
+```
+
+### 4. Start AGL Demo Control Panel
+
+1. To start the control panel
+	```
+	$ cd /Path/to/agl-demo-control-panel
+	$ source control-panel/bin/activate
+	$ python -u main.py
+	```
+
+![Layers_And_Extensions](images/AGL-Demo-Control-Panel/Dashboard.png)
+
+2. Go to settings
+	- Start (load default config from drop-down menu)
+	-  Configure: make changes as required
+		- IP-Address
+		- Port
+		- Secure Mode: if toggled **"on"**, specify the `CA.pem File`
+		- Protocol: websocket ← ? → gRPC
+		- TLS Server Name
+		- JWT/Auth Token path 
+		- CA.pem certificate path
+	- Start/Stop
+	- Reconnect
+	- Page settings: Configure the visibility of pages and switch between CAN and Kuksa messages by using the toggle for the same.
+
+![Layers_And_Extensions](images/AGL-Demo-Control-Panel/Settings_Page.png)
+
+1. Navigate to the desired page using the provided buttons at the bottom
+
+|  |
+|---|
+| ![Layers_And_Extensions](images/AGL-Demo-Control-Panel/IC.png) |
+
+|  |  |
+|---|---|
+| ![Layers_And_Extensions](images/AGL-Demo-Control-Panel/HVAC.png) | ![Layers_And_Extensions](images/AGL-Demo-Control-Panel/SC.png) |
diff --git a/docs/05_Component_Documentation/10_agl_voice_agent_assistant.md b/docs/05_Component_Documentation/10_agl_voice_agent_assistant.md
new file mode 100644
index 0000000..97bdd0d
--- /dev/null
+++ b/docs/05_Component_Documentation/10_agl_voice_agent_assistant.md
@@ -0,0 +1,286 @@
+---
+title: AGL Voice Agent / Assistant
+---
+
+# AGL Voice Agent / Assistant
+
+# Introduction
+A gRPC-based voice agent designed for Automotive Grade Linux (AGL). This service leverages GStreamer, Vosk, Snips, and RASA to seamlessly process user voice commands. It converts spoken words into text, extracts intents from these commands, and performs actions through the Kuksa interface. The voice agent is designed to be modular and extensible, allowing for the addition of new speech recognition and intent extraction models.
+
+# Installation and Usage
+Before we dive into the detailed components documentation, let's first take a look at how to install and use the voice agent service. All of the features of the voice agent service are encapsulated in the `meta-offline-voice-agent` sub-layer which can be found under `meta-agl-devel` layer. These features are currently part of the `master` branch only. This sub-layer can be built into the final image by using following commands:
+
+```shell
+$ source master/meta-agl/scripts/aglsetup.sh -m qemux86-64 -b build-master agl-demo agl-devel agl-offline-voice-agent
+$ source agl-init-build-env
+$ bitbake agl-ivi-demo-flutter
+```
+
+After the build is complete, you can run the final image using QEMU. Once the image is running, you can start the voice agent service by running the following command:
+```shell
+$ voiceagent-service run-server --default
+```
+
+The `--default` flag loads the voice agent service with default configuration. The default configuration file looks like this:
+```ini
+[General]
+base_audio_dir = /usr/share/nlu/commands/
+stt_model_path = /usr/share/vosk/vosk-model-small-en-us-0.15/
+wake_word_model_path = /usr/share/vosk/vosk-model-small-en-us-0.15/
+snips_model_path = /usr/share/nlu/snips/model/
+channels = 1
+sample_rate = 16000
+bits_per_sample = 16
+wake_word = hello auto
+server_port = 51053
+server_address = 127.0.0.1
+rasa_model_path = /usr/share/nlu/rasa/models/
+rasa_server_port = 51054
+rasa_detached_mode = 0
+base_log_dir = /usr/share/nlu/logs/
+store_voice_commands = 0
+
+[Kuksa]
+ip = 127.0.0.1
+port = 8090
+protocol = ws
+insecure = True
+token = /usr/lib/python3.10/site-packages/kuksa_certificates/jwt/super-admin.json.token
+
+[Mapper]
+intents_vss_map = /usr/share/nlu/mappings/intents_vss_map.json
+vss_signals_spec = /usr/share/nlu/mappings/vss_signals_spec.json
+```
+
+Most of the above configuration variable are self explanatory, however, I'll dive deeper into the ones that might need some explanation.
+
+- **`store_voice_commands`**: This variable is used to enable/disable the storage of voice commands. If this variable is set to `1`, then the voice commands will be stored in the `base_audio_dir` directory. The voice commands are stored in the following format: `base_audio_dir/<timestamp>.wav`. The `timestamp` is the time at which the voice command was received by the voice agent service.
+
+- **`rasa_detached_mode`**: This variable is used to enable/disable the detached mode for the RASA NLU engine. If this variable is set to `1`, then the RASA NLU engine will be run in detached mode, i.e. the voice agent service won't run it and will assume that RASA is already running. This is useful when you want to run the RASA NLU engine on a separate machine. If this variable is set to `0`, then the RASA NLU engine will be run as a sub process of the voice agent service.
+
+- **`intents_vss_map`**: This is the path to the file that actually maps the intent output from our intent engine to the VSS signal specification. This file is in JSON format and contains the mapping for all the intents that we want to support. The default file looks like this:
+
+    ```json
+    {
+    "intents": {
+        "VolumeControl": {
+            "signals": [
+                "Vehicle.Cabin.Infotainment.Media.Volume"
+            ]
+        },
+        "HVACFanSpeed": {
+            "signals": [
+                "Vehicle.Cabin.HVAC.Station.Row1.Left.FanSpeed",
+                "Vehicle.Cabin.HVAC.Station.Row1.Right.FanSpeed",
+                "Vehicle.Cabin.HVAC.Station.Row2.Left.FanSpeed",
+                "Vehicle.Cabin.HVAC.Station.Row2.Right.FanSpeed"
+            ]
+        },
+        "HVACTemperature": {
+            "signals": [
+                "Vehicle.Cabin.HVAC.Station.Row1.Left.Temperature",
+                "Vehicle.Cabin.HVAC.Station.Row1.Right.Temperature",
+                "Vehicle.Cabin.HVAC.Station.Row2.Left.Temperature",
+                "Vehicle.Cabin.HVAC.Station.Row2.Right.Temperature"
+            ]
+        }
+    }
+    }
+    ```
+    Notice that `VolumeControl`, `HVACFanSpeed`, and `HVACTemperature` are the intents that we want to support. The `signals` array contains the VSS signals that we want to change when the user issues a command for that intent. For example, if the user says "Set the volume to 50", then the voice agent service will extract the `VolumeControl` intent from the user's command and then change the `Vehicle.Cabin.Infotainment.Media.Volume` signal to 50.
+
+- **`vss_signal_spec`**: This is path to the file that defines the specs and values that can be mapped onto a VSS signal. This file is in JSON format and contains specs for all the VSS signal that we want to support. A sample VSS spec definition looks like this:
+
+    ```json
+    {
+    "signals": {
+        "Vehicle.Cabin.Infotainment.Media.Volume": {
+            "default_value": 15,
+            "default_change_factor": 5,
+            "actions": {
+                "set": {
+                    "intents": ["volume_control_action"],
+                    "synonyms": ["set", "change", "adjust"]
+                },
+                "increase": {
+                    "intents":["volume_control_action"],
+                    "synonyms": ["increase", "up", "raise", "louder"],
+                    "modifier_intents": ["to_or_by"]
+                }, 
+                "decrease": {
+                    "intents": ["volume_control_action"],
+                    "synonyms": ["decrease", "lower", "down", "quieter", "reduce"],
+                    "modifier_intents": ["to_or_by"]
+                }
+            },
+            "values": {
+                "ranged": true,
+                "start": 1,
+                "end": 100,
+                "ignore": [],
+                "additional": []
+            },
+            "default_fallback": true,
+            "value_set_intents": {
+                "numeric_value": {
+                    "datatype": "number",
+                    "unit": "percent"
+                }
+            }
+        }
+    }
+    }
+    ```
+    Notice that `Vehicle.Cabin.Infotainment.Media.Volume` is the VSS signal that whose specification we want to define. The `default_value` is the default value of the signal to use if the user doesn't specify a value in their command. The `default_change_factor` is the default change factor of the signal, i.e the value to increment or decrement the current value with if user didn't specify any specific change factor. The `actions` object defines the actions that can be performed on the signal, currently, only "increase", "decrease", and "set" are supported. The `values` object defines the range of values that can be mapped onto the signal. The `value_set_intents` object defines the intent (or the `slot` to be more precise) that contains the specific value of the signal defined by the user in their command. Here `numeric_value` is the slot that contains the value of the signal as defined during the training of the intent engine. The `datatype` is the type of the value, i.e. `number`, `string`, `boolean`, etc. The `unit` is the unit of the value, i.e. `percent`, `degree`, `celsius`, etc.
+
+
+If you want to change the default configuration, you can do so by creating a new configuration file and then passing it to the voice agent service using the `--config` flag. For example:
+```shell
+$ voiceagent-service run-server --config path/to/config.ini
+```
+
+One thing to note here is that all the directory paths in the configuration file should be absolute and always end with a `/`.
+
+# High Level Architecture
+![Voice_Agent_Architecture](images/agl-voice-agent/AGL_Offline_VoiceAgent_(High_Level_Architecture).png)
+
+# Components
+- Voice Agent Service
+    - Vosk Kaldi
+    - Snips
+    - RASA
+- Voice Assistant App
+
+# Voice Agent Service
+The voice agent service is a gRPC-based service that is responsible for converting spoken words into text, extracting intents from these commands, and performing actions through the Kuksa interface. The service is composed of three main components: Vosk Kaldi, RASA, and Snips.
+
+## Vosk Kaldi
+Vosk Kaldi is a speech recognition toolkit that is based on Kaldi and Vosk. It is used to convert spoken words into text. It provides us with some official pre-trained models for various popular languages. We can also train our own models using the Vosk Kaldi toolkit. The current voice agent service requires two different models to run, one for **wake-word detection** and one for **speech recognition**. The wake word detection model is used to detect when the user says the wake word, which is "Hey Automotive" by default, we can easily change the default wake word by modifying the config file. The speech recognition model is used to convert the user's spoken words into text.
+
+## Snips
+Snips NLU (Natural Language Understanding) is a Python based Intent Engine that allows to extract structured information from sentences written in natural language. The NLU engine first detects what the intention of the user is (a.k.a. intent), then extracts the parameters (called slots) of the query. The developer can then use this to determine the appropriate action or response. Our voice agent service uses either Snips or RASA to extract intents from the user's spoken commands.
+
+It is recommended to take a brief look at [Snips Official Documentation](https://snips-nlu.readthedocs.io/en/latest/) to get a better understanding of how Snips works.
+
+### Dataset Format
+The Snips NLU engine uses a dataset to understand and recognize user intents. The dataset is structured into two files:
+
+- `intents.yaml`: Contains the intent definitions, slots, and sample utterances for each intent.
+- `entities.yaml`: Defines the entities used in the intents, including their values, synonyms, and matching strictness.
+
+To train the NLU Intent Engine model, a pre-processing step is required to convert the dataset into a format compatible with the Snips NLU engine. Once the model is trained, it can be used to parse user queries and extract the intent and relevant slots for further processing.
+
+### Training
+To train the NLU Intent Engine for your specific use case, you can modify the dataset files `intents.yaml` and `entities.yaml` to add new intents, slots, or entity values. You need to re-generate the dataset if you modify `intent.yaml` or `entities.yaml`, for this purpose you need to install [`snips-sdk-agl`](https://github.com/malik727/snips-sdk-agl) module. This module is an extension of the original Snips NLU with upgraded Python support and is specifically designed for data pre-processing and training purposes only. 
+
+After installation run the following command to generate the updated `dataset.json` file:
+```shell
+$ snips-sdk generate-dataset en entities.yaml intents.yaml > dataset.json
+```
+
+Then run the following command to re-train the model:
+```shell
+$ snips-sdk train path/to/dataset.json path/to/model
+```
+
+Finally, you can use the [`snips-inference-agl`](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/snips-inference-agl.git;a=summary) module to process commands and extract the associated intents.
+
+### Usage
+To set up and run the Snips NLU Intent Engine, follow these steps:
+
+1. Train your model by following the steps laid earlier or just clone a pre-existing model from [here](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/snips-model-agl.git;a=summary).
+
+2. Install and set up the [`snips-inference-agl`](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/snips-inference-agl.git;a=summary) module on your local machine. This module is an extension of the original Snips NLU with upgraded Python support and is specifically designed for inference purposes only.
+
+3. Once you have the [`snips-inference-agl`](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/snips-inference-agl.git;a=summary) module installed, you can load the pre-trained model located in the model/ folder. This model contains the trained data and parameters necessary for intent extraction. You can use the following command to process commands and extract the associated intents:
+    ```shell
+    $ snips-inference parse path/to/model -q "your command here"
+    ```
+
+### Observations
+- The Snips NLU engine is very lightweight and uses around 250 MB - 300 MB of RAM when running on the target device.
+- The underlying AI arhictecture of the Snips NLU is not extensible or changeable.
+- The Snips NLU engine is not very accurate as compared to RASA, however, its extremely lightweight and really fast.
+
+## RASA
+RASA is an open-source machine learning framework for building contextual AI assistants and chatbots. It is based on Python and TensorFlow. It is used to extract intents from the user's spoken commands. The RASA NLU engine is trained on a dataset that contains intents, entities, and sample utterances. The RASA NLU engine is used to parse user queries and extract the intent and relevant entities for further processing.
+
+It is recommended to take a brief look at [RASA Official Documentation](https://rasa.com/docs/rasa/) to get a better understanding of how RASA works.
+
+### Dataset Format
+Rasa uses YAML as a unified and extendable way to manage all training data, including NLU data, stories and rules.
+
+You can split the training data over any number of YAML files, and each file can contain any combination of NLU data, stories, and rules. The training data parser determines the training data type using top level keys.
+
+NLU training data consists of example user utterances categorized by intent. Training examples can also include entities. Entities are structured pieces of information that can be extracted from a user's message. You can also add extra information such as regular expressions and lookup tables to your training data to help the model identify intents and entities correctly. Example dataset for `check_balance` intent:
+
+```yaml
+nlu:
+- intent: check_balance
+  examples: |
+    - What's my [credit](account) balance?
+    - What's the balance on my [credit card account]{"entity":"account","value":"credit"}
+
+- synonym: credit
+  examples: |
+    - credit card account
+    - credit account
+```
+
+### Training
+To train the RASA NLU intent engine model you need to curate a dataset for your sepcific use case. You can also use the [RASA NLU Trainer](https://rasahq.github.io/rasa-nlu-trainer/) to curate your dataset. Once you have your dataset ready, now you need to create a `config.yml` file. This file contains the configuration for the RASA NLU engine. A sample `config.yml` file is given below:
+
+```yaml
+language: en  # your 2-letter language code
+assistant_id: 20230807-130137-kind-easement
+
+pipeline:
+  - name: WhitespaceTokenizer
+  - name: RegexFeaturizer
+  - name: LexicalSyntacticFeaturizer
+  - name: CountVectorsFeaturizer
+  - name: CountVectorsFeaturizer
+    analyzer: "char_wb"
+    min_ngram: 1
+    max_ngram: 4
+  - name: DIETClassifier
+    epochs: 100
+    constrain_similarities: true
+  - name: EntitySynonymMapper
+  - name: ResponseSelector
+    epochs: 100
+    constrain_similarities: true
+  - name: FallbackClassifier
+    threshold: 0.3
+    ambiguity_threshold: 0.1
+```
+
+Now download RASA (v3.6.4) using the following command:
+```shell
+$ pip install rasa==3.6.4
+```
+Finally, you can use the following command to train the RASA NLU engine:
+```shell
+$ rasa train nlu --config config.yml --nlu path/to/dataset.yml --out path/to/model
+```
+
+### Usage
+To set up and run the RASA NLU Intent Engine, follow these steps:
+
+1. Train your model by following the steps laid earlier or just clone a pre-existing model from [here](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/rasa-model-agl.git;a=summary).
+
+2. Once you have RASA (v3.6.4) installed, you can load the pre-trained model located in the model/ folder. This model contains the trained data and parameters necessary for intent extraction. You can use the following command to process commands and extract the associated intents:
+    ```shell
+    $ rasa shell --model path/to/model
+    ```
+
+### Observations
+- The RASA NLU engine is heavy and uses around 0.8 GB - 1 GB of RAM when running on the target device.
+- The underlying AI arhictecture of the RASA NLU is extensible and changeable thanks to the TensorFlow backend.
+- The RASA NLU engine is very accurate as compared to Snips, however, its heavy and slightly slow.
+
+# Voice Assistant App
+The voice assistant app is a flutter based application made for Automotive Grade Linux (AGL). It is responsible for interacting with the voice agent service for user voice command recognition, intent extraction, and command execution. It also receives the response from the voice agent service and displays it on the screen. Some app UI screenshots are attached below.
+
+![Voice_Agent_App_1](images/agl-voice-agent/voice-assistant-flutter-1.png)
+![Voice_Agent_App_2](images/agl-voice-agent/voice-assistant-flutter-2.png)
diff --git a/docs/05_Component_Documentation/11_Unified_HMI.md b/docs/05_Component_Documentation/11_Unified_HMI.md
new file mode 100644
index 0000000..5076a60
--- /dev/null
+++ b/docs/05_Component_Documentation/11_Unified_HMI.md
@@ -0,0 +1,165 @@
+---
+title: Unified HMI
+---
+# Unified HMI
+
+## Introduction
+
+This document describes the design and usage of the **Unified HMI**, which is a common platform technology for UX innovation in integrated cockpit by flexible information display on multiple displays of various applications. Applications can be rendered to any display via a unified virtual display.
+
+### Remote Virtio GPU (RVGPU)
+
+The RVGPU rendering engine, operating on a client-server model, creates 3D rendering commands on a client device and transmits them to a server device via the network, where the server-side device performs GPU-based rendering and displays the results. The meta-rvgpu currently supports x86, Raspberry Pi 4, and Renesas Boards platforms.
+
+### RVGPU Architecture
+
+![RVGPU_Architecture](images/Unified-HMI/RVGPU_Architecture.png)
+
+## How to Build  
+
+Follow the [AGL documentation](https://docs.automotivelinux.org/en/ricefish/#01_Getting_Started/02_Building_AGL_Image/01_Build_Process_Overview/) for the build process, and set up the "[Initializing Your Build Environment](https://docs.automotivelinux.org/en/master/#01_Getting_Started/02_Building_AGL_Image/04_Initializing_Your_Build_Environment/)" section as described below to enable the AGL feature 'agl-rvgpu'. For example:
+```
+$ cd $AGL_TOP/master
+$ source ./meta-agl/scripts/aglsetup.sh -m qemux86-64 -b qemux86-64 agl-demo agl-devel agl-rvgpu
+```
+After adding the feature, execute the command:
+```
+$ bitbake <image_name>
+```
+**Note**: The operation has been confirmed with the **agl-ivi-demo-qt**. If you wish to specify a different `<image_name>` other than agl-ivi-demo-qt, create a file named `<image_name>.bbappend` in the directory
+```
+$AGL_TOP/master/meta-agl-devel/meta-uhmi/meta-rvgpu/recipes-platform/images
+```
+, and then add the following line to the file:
+
+```
+IMAGE_INSTALL:append = " packagegroup-rvgpu"
+```
+
+After making this change, you will need to execute the following commands:
+
+```
+$ cd $AGL_TOP/master
+$ source agl-init-build-env
+$ bitbake <image_name>
+``` 
+
+## How to Setup and Boot
+
+For Environment setup instructions for each platform, refer to the following link in the AGL Documentation.  
+[Building for x86(Emulation and Hardware)](https://docs.automotivelinux.org/en/master/#01_Getting_Started/02_Building_AGL_Image/07_Building_for_x86_%28Emulation_and_Hardware%29/)  
+[Building for Raspberry Pi 4](https://docs.automotivelinux.org/en/master/#01_Getting_Started/02_Building_AGL_Image/08_Building_for_Raspberry_Pi_4/)  
+[Building for Supported Renesas Boards](https://docs.automotivelinux.org/en/master/#01_Getting_Started/02_Building_AGL_Image/09_Building_for_Supported_Renesas_Boards/)
+
+For Raspberry Pi 4 and Supported Renesas Boards, refer to the above URL for boot methods.  
+For x86 emulation (qemu), network bridge is required to enable communication with other devices when using RVGPU. Here’s an example procedure for your reference.
+```
+$ sudo ip link add <bridge_name> type bridge
+$ sudo ip addr add <IP address> dev <bridge_name>
+$ sudo ip link set dev <interface> master <bridge_name>
+$ sudo ip link set dev <bridge_name> up
+```
+Replace the placeholders with the appropriate values: 
+- `<bridge_name>`: You can assign any name, for example: `br0`
+- `<IP_address>`: Enter an available IP address, for example: `192.168.0.100/24`
+- `<interface>`: Specify the network interface, for example: `eth0`
+
+To enable the use of the bridge, create or append /etc/qemu directory and /etc/qemu/bridge.conf file.
+```
+allow <bridge_name>
+```
+Make sure /etc/qemu/ has 755 permissions.  
+Create the following bash file named **run_qemu_bridge.sh** in any `<WORKDIR>`.
+```
+#!/bin/bash
+
+KERNEL_PATH=$1
+DRIVE_PATH=$2
+BRIDGE_NAME="<bridge_name>"
+
+printf -v macaddr "52:54:%02x:%02x:%02x:%02x" $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff )) $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff ))
+
+qemu-system-x86_64 -enable-kvm -m 2048 \
+    -kernel ${KERNEL_PATH} \
+    -drive file=${DRIVE_PATH},if=virtio,format=raw \
+    -cpu kvm64 -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt \
+    -vga virtio -show-cursor \
+    -device virtio-net-pci,netdev=net0,mac=$macaddr \
+    -netdev bridge,br=$BRIDGE_NAME,id=net0 \
+    -serial mon:stdio -serial null \
+    -soundhw hda \
+    -append 'root=/dev/vda rw console=ttyS0,115200n8 fstab=no'
+```
+Save the file and run the following to start QEMU.
+```
+sudo <WORKDIR>/run_qemu_bridge.sh <build_directory>/tmp/deploy/images/qemux86-64/bzImage <build_directory>/tmp/deploy/images/qemux86-64/agl-ivi-demo-qt-qemux86-64.ext4
+```
+When QEMU boot, assign an IP address. For example:
+```
+ifconfig <your environment> 192.168.0.10 netmask 255.255.255.0
+```
+
+## How to run RVGPU remotely
+Prepare two images, one as the Sender and the other as the Receiver.
+It is necessary for the Sender and Receiver to be within the same network.
+
+**Receiver side**  
+```
+$ export XDG_RUNTIME_DIR=/run/user/<your_UID>
+$ rvgpu-renderer -b <your_Area>@0,0 -p <Port_Number> &
+```
+
+Replace the placeholders with the appropriate values:
+- `<your_UID>`: Specify according to your environment, for example:1001
+- `<your_Area>`: Enter an usable area for example: 1080x1488  
+ With the following command, you can know the usable area.
+  ```
+  $ journalctl | grep -i "usable area"
+  # Example Output:
+  Nov 29 11:42:53 qemux86-64 agl-compositor[259]: [11:42:53.166] Usable area: 1080x1488+0,216
+  ```
+- `<Port_Number>`: Enter an available port number, for example: 55555
+
+
+**Sender side**  
+Create the following shell script **run_remote_app.sh** in any `<WORKDIR>` for a smooth experience.
+```
+#!/bin/bash
+
+export XDG_RUNTIME_DIR=/tmp
+export LD_LIBRARY_PATH=/usr/lib/mesa-virtio
+
+# -------------
+# launch app
+# -------------
+$@
+```
+
+Save the file and run the following to start weston.
+
+```
+$ rvgpu-proxy -s 1080x1488@0,0 -n <IP_address_of_Receiver>:<Port_Number> &
+$ <WORKDIR>/run_remote_app.sh weston --backend drm-backend.so -Swayland-0 --seat=seat_virtual -i 0 &
+```  
+Replace the placeholders with the appropriate values:
+- `<Port_Number>`: Port set in the renderer.
+
+
+After completing these steps, the Weston screen from the Sender will be transferred and displayed on the Receiver using rvgpu-proxy and rvgpu-renderer. You can verify that everything is functioning properly by launching wayland applications on the Sender side, such as:
+```
+$ weston-simple-egl -f
+``` 
+
+You can also verify the touch or keyboard operation support of the RVGPU by using app such as 
+```
+$ weston-smoke
+$ weston-editor
+```
+**Note**: There are known issues with mouse, such as the cursor becoming invisible and occasional flickering of a green screen.
+
+**Appendix**  
+- By building the RVGPU on Ubuntu, it is possible to enable bidirectional remote rendering between the agl-ivi-demo-qt and Ubuntu.  
+For the build procedure on Ubuntu, see the following URL: https://github.com/unified-hmi/remote-virtio-gpu  
+The figure below shows an example where Ubuntu is used as the Sender and AGL as the Receiver, running RVGPU.
+
+![Using_RVGPU_from_Ubuntu_to_AGL](images/Unified-HMI/Using_RVGPU_from_Ubuntu_to_AGL.png)
\ No newline at end of file
diff --git a/docs/05_Component_Documentation/12_AGL_Persistent_Storage_API.md b/docs/05_Component_Documentation/12_AGL_Persistent_Storage_API.md
new file mode 100644
index 0000000..97ec0ac
--- /dev/null
+++ b/docs/05_Component_Documentation/12_AGL_Persistent_Storage_API.md
@@ -0,0 +1,225 @@
+# Persistent Storage API for the Automotive Grade Linux demo
+
+The [AGL Persistent Storage API](https://github.com/LSchwiedrzik/agl-persistent-storage-api)
+is a grpc API for [AGL](https://www.automotivelinux.org/) 
+that serves as persistent storage API for the demo. The API is written 
+in Rust and makes use of [tonic](https://crates.io/crates/tonic-build) for grpc
+functionality as well as [RocksDB](https://rocksdb.org/) as a database backend,
+using [rust-rocksdb](https://crates.io/crates/rust-rocksdb). Use cases include
+retaining settings over a system shutdown (e.g. audio, HVAC, profile data, Wifi
+settings, radio presets, metric vs imperial units).
+
+The most important hardware consideration for this project is that the AGL demo
+runs on embedded hardware with flash storage, so we want to minimize number of
+write operations. This impacts the choice of database; we have chosen to work
+with RocksDB as it is well-suited for embedded computing and tunable with
+respect to write amplification. In principle the API is flexible with
+respect to database used (pluggable backends), but only RocksDB is implemented. 
+This API is part of the AGL demo as of release 'Royal Ricefish'.
+
+The AGL Persistent Storage API is constructed using a layered architecture:
+
+- Controller layer: translates proto calls to service calls.
+- Service layer: communicates with the controller and facade layers, implements
+  the business logic
+- Facade layer: implements RocksDB.
+
+## API Specification
+
+**Namespaces**
+The rpcs described below interact with keys belonging to specific namespaces. This feature enables applications to maintain private namespaces within the same database. Not specifying a namespace when calling the API will result in the default namespace "" being used. Alternatively, a specific namespace (e.g. "AppName") can be chosen. With the exception of DestroyDB, which acts on the entire database, all rpcs can only interact with one namespace at a time.
+
+- `DestroyDB() -> StandardResponse(success: boolean, message: string)`
+
+  - Consumer wants to destroy the entire database.
+
+    ```text
+    DestroyDB() -> //destroys entire database.
+    ```
+
+- `Write(key: string, value: string, namespace: string) -> StandardResponse(success: boolean, message: string)`
+
+  - Consumer wants to save *key* + *value* to a given *namespace* (default is ""), (e.g.
+    'Vehicle.Infotainment.Radio.CurrentStation':'hr5').
+  - This overwrites existing *value* under *key*.
+  - An empty string cannot be used as a *key*.
+
+    ```text
+    Write('Vehicle.Infotainment.Radio.CurrentStation':'wdr 4') -> Response
+
+    Write('Vehicle.Infotainment':'yes') -> Response
+
+    Write('test':'1') -> Response
+
+    Write('':'test') -> Error
+
+    Write(key: 'Private.Info', value: 'test', namespace: 'AppName') -> Response
+    ```
+
+- `Read(key: string, namespace: string) -> ReadResponse(success: boolean, message: string, value: string)`
+
+  - Consumer wants to read *value* of existing *key* in a given *namespace* (default is ""), e.g.
+    'Vehicle.Infotainment.Radio.CurrentStation':
+
+    ```text
+    Read('Vehicle.Infotainment.Radio.CurrentStation') -> 'wdr 4'
+
+    Read('Vehicle.doesNotExist') -> ERROR
+
+    Read(key: 'Private.Info', namespace: 'AppName') -> 'test'
+    ```
+
+- `Delete(key: string, namespace: string) -> StandardResponse(success: boolean, message: string)`
+
+  - Consumer wants to delete an existing *key* + *value* from a given *namespace* (default is ""), e.g.
+    'Vehicle.Infotainment.Radio.CurrentStation':
+
+    ```text
+    Delete('Vehicle.Infotainment.Radio.CurrentStation') -> Response
+
+    Delete('Vehicle.doesNotExist') -> ERROR
+
+    Delete(key: 'Private.Info', namespace: 'AppName') -> Response
+    ```
+
+- `Search(key: string, namespace: string) -> ListResponse(success: boolean, message: string, keys: repeated string)`
+
+  - Consumer wants to list all keys that contain *key* in a given *namespace* (default is ""), e.g. 'Radio'
+
+    ```text
+    Search('Radio') -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Communication.Radio.Volume')
+
+    Search('Info') -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature')
+
+    Search('nt.Rad') -> ('Vehicle.Infotainment.Radio.CurrentStation')
+
+    Search('') -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume')
+
+    Search(key: '', namespace: 'AppName') -> ('Private.Info')
+    ```
+
+- `DeleteNodes(key: string, namespace: string) -> StandardResponse(success: boolean, message: string)`
+
+  - Consumer wants to delete all keys located in the subtree with root *key*, within the given *namespace* (default is ""), e.g.
+    'Vehicle.Infotainment'
+  - `key = ''` returns `ERROR`
+  - This rpc assumes that keys follow a VSS-like tree structure.
+
+    ```text
+    DeleteNodes('Vehicle.Infotainment') -> Response //deletes ('Vehicle.Infotainment', 'Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature')
+
+    DeleteNodes('Vehicle') -> Response //deletes ('Vehicle.Infotainment', 'Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume')
+
+    DeleteNodes('') -> ERROR
+
+    DeleteNodes('DoesNotExist') -> ERROR
+
+    DeleteNodes('Vehic') -> ERROR
+
+    DeleteNodes(key: 'Private', namespace: 'AppName') -> Response //deletes ('Private.Info')
+    ```
+
+- `ListNodes(node: string, layers: optional int, namespace: string) -> ListResponse(boolean, message, repeated string keys)`
+
+  - Consumer wants to list all nodes located in the subtree with root *node* exactly *layers*
+    layers deep, within the given *namespace* (default is "") , e.g. 'Vehicle.Infotainment'
+
+    - `layers = 0` lists all keys that start in *node* any number of *layers* deep
+    - `layers` default value is 1
+    - `node = ''` returns top-level root node(s)
+    - This rpc assumes that keys follow a VSS-like tree structure.
+
+    ```text
+    ListNodes('Vehicle.Infotainment', 1) -> ('Vehicle.Infotainment.Radio', 'Vehicle.Infotainment.HVAC')
+
+    ListNodes('Vehicle.Infotainment', 2) -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature')
+
+    ListNodes('Vehicle', 0) -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume', 'Vehicle.Infotainment')
+
+    ListNodes('', 0) -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume', 'Vehicle.Infotainment', 'test')
+
+    ListNodes('Vehicle.Infotainment') -> ('Vehicle.Infotainment.Radio', 'Vehicle.Infotainment.HVAC')
+
+    ListNodes('', 1) -> ('Vehicle', 'test')
+
+    ListNodes('Vehicle.Infotainment.Radio.Volume', 1) -> ()
+
+    ListNodes('Vehicle', -1) -> ERROR
+
+    ListNodes('Vehicle.DoesNotExist', 1) -> ERROR
+
+    ListNodes(key: 'Private', namespace: 'AppName') -> ('Private.Info')
+
+    For empty data base:
+    ListNodes('', 1) -> ()
+    ```
+
+## Example Tree
+
+Note: nodes marked by \* are keys (and therefore have a value)
+
+**Namespace: ""**
+- Vehicle
+  - Infotainment \*
+    - Radio
+      - CurrentStation \*
+      - Volume \*
+    - HVAC
+      - OutdoorTemperature \*
+  - Communication
+    - Radio
+      - Volume \*
+- test \*
+
+**Namespace: "AppName"**
+- Private
+  - Info \*
+
+## Setup instructions
+
+1. Install rust
+
+2. Download or install protobuf (e.g. from
+   [here](https://github.com/protocolbuffers/protobuf/releases)) and set the
+   `PROTOC` environment variable:
+   `echo -n "export PROTOC=/path/to/protoc.exe" >> ~/.bashrc`
+   
+3. Build application
+
+   ```bash
+   cargo build
+   ```
+
+4. Run tests
+
+   ```bash
+   cargo test
+   ```
+
+5. Start server
+
+   ```bash
+   cargo run --release --bin server
+   ```
+
+## rpc Usage
+
+Insomnia usage for manual testing is describd in
+https://konghq.com/blog/engineering/building-grpc-apis-with-rust
+
+```text
+DestroyDB: {}
+
+Write: { "key": "foo", "value": "foobar", "namespace": "bar" }
+
+Read: { "key": "foo", "namespace": "bar" }
+
+Delete: { "key": "foo", "namespace": "bar" }
+
+Search: { "key": "foo", "namespace": "bar" }
+
+DeleteNodes: { "key": "foo", "namespace": "bar" }
+
+ListNodes: { "key": "foo", "layers": 1, "namespace": "bar" }
+
+```
diff --git a/docs/05_Component_Documentation/Application_Framework/01_Introduction.md b/docs/05_Component_Documentation/Application_Framework/01_Introduction.md
new file mode 100644
index 0000000..32c6bb0
--- /dev/null
+++ b/docs/05_Component_Documentation/Application_Framework/01_Introduction.md
@@ -0,0 +1,164 @@
+---
+title: Introduction
+---
+
+# Foreword
+
+AGL has worked at providing the components of an application framework for many
+years. However, the implementation used up until the `lamprey` release was retired
+starting with the `marlin` release, and replaced with a redesigned one.
+However, this new implementation does not aim to be a 1:1 replacement, and as such
+it does not provide all of the features of the previous framework. Some of those
+will be added back over time, while others have been discarded in favor of more
+modern and/or widely-used alternatives.
+
+With the `needlefish` release, further evolution of the replacement framework included:
+
+- Using [gRPC IPC](https://grpc.io/about) for the application launcher API.
+  The interim D-Bus based API was deprecated at this time, and removed in the
+  `ricefish` release.
+- Using only systemd unit metadata in the application launcher instead of using
+  [Desktop Entry specification](https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/)
+  to list applications, and relying entirely on systemd for the application
+  lifecycle, rather than spawning them directly.
+
+# Introduction
+
+With a goal of being the provider of an integrated solution to build up on, it
+is useful for AGL to define a reliable and well-specified method for managing
+the deployment and integration of applications and services, as well as the way
+they can interact with the rest of the system.
+
+This is achieved by providing a common set of rules and components, known as
+the application framework. By documenting those rules, application developers can
+have a good understanding of the requirements for creating and packaging applications
+targeting AGL-based systems that leverage the upstream application framework components.
+Likewise, system developers and integrators have a clear path for including such
+applications in AGL-based products.
+
+The application framework's scope extends to the following areas:
+
+- system services integration and lifecycle management
+- user-level application lifecycle management
+- inter-process communication
+
+In order to be as simple as possible and avoid any unneeded custom
+implementation, the application framework relies mainly on third-party
+technologies and/or software components. They include:
+
+- [systemd](https://www.freedesktop.org/wiki/Software/systemd/): system
+  services and user session services management
+
+- [gRPC](https://grpc.io/about): inter-process communication, new recommmended
+  system-wide IPC, which should be used instead of D-Bus.
+
+Note that while there are many open source software projects in the desktop Linux
+space using [D-Bus](https://www.freedesktop.org/wiki/Software/dbus/) for inter-process
+communication, AGL has decided to avoid using it for new development projects for the
+following reasons:
+
+- It has proven challenging in the past to manage dependencies between and the
+  start-up of system and per-user D-Bus services in AGL.
+- Managing the security of D-Bus APIs involves the use of PolicyKit, which is
+  somewhat heavyweight and not widely understood. As well, providing D-Bus
+  access to applications running inside containers or other sandbox schemes can
+  be significantly more complicated than e.g. using gRPC with authorization token
+  access control.
+- D-Bus is not widely used in application development ecosystems outside of desktop
+  Linux. This matters when engaging with application developers in newer ecosystems
+  such as web applications or Flutter.
+
+AGL also provides reference implementations whenever possible and relevant,
+located in the [meta-agl](../../04_Developer_Guides/02_AGL_Layers/02_meta_agl.md)
+layer under `meta-app-framework`. At the moment, the application framework
+contains two such components:
+
+- `agl-session`: `systemd` unit files for user sessions management
+- `applaunchd`: application launcher service
+
+# Service Management
+
+Both system and user services are managed by `systemd`, which provides a number
+of important features, such as dependency management or service monitoring:
+when starting a service, `systemd` will ensure any other units this service
+depends on are available, and otherwise start those dependencies. Similarly,
+`systemd` can automatically restart a crashed service, ensuring minimal
+downtime.
+
+`systemd` also provides an efficient first layer of security through its
+[sandboxing](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxing)
+and other security-related options.
+
+It is also well integrated with D-Bus and can be used for a more fine-grained
+control over D-Bus activated services.  By delegating the actual service start-up
+to `systemd`, developers can take advantage of its advanced features, allowing
+for improved reliability and security.
+
+Each service should be represented by a `systemd` unit file installed to the
+appropriate location. More details can be obtained from the [Creating a New
+Service](../../04_Developer_Guides/03_Creating_a_New_Service.md) document.
+
+# User Session Management
+
+Similarly, user sessions and the services they rely on are also managed by
+`systemd`.  Prior to the `ricefish` release, AGL used a user session for the
+`agl-driver` user for the running of user facing applications, including the
+compositor. This has been replaced with using system units that use the
+`User` directive. The reason for this is two-fold:
+
+- Several useful systemd sandboxing features are unavailable to user session
+  units, or would require the use of unprivileged namespace mounting.  The
+  latter is not necessarily available in vendor BSP kernels, and the security
+  characteristics of it are still a matter of some debate.
+- Encoding dependencies between user session and system units is sometimes
+  not straightforward or impossible.
+
+# Inter-process Communication
+
+In order to provide a language-independent, "standard", IPC mechanism and avoid
+the need for maintaining custom bindings for each programming language to be
+used on top of AGL, the application framework previously promoted the use of
+[D-Bus](https://www.freedesktop.org/wiki/Software/dbus/) as the preferred way
+for applications to interact with services. Starting with `needlefish` release,
+this has changed to recommending [gRPC](https://grpc.io) for our system-wide IPC,
+with D-Bus being kept to provide functionality to services and applications
+which haven't transitioned yet to using gRPC.
+
+Most services already included in AGL provide one or several D-Bus interfaces,
+and can therefore interact with D-Bus capable applications and services
+without requiring any additional component. Those services include, among
+others:
+
+- [ConnMan](https://git.kernel.org/pub/scm/network/connman/connman.git/):
+  network connectivity
+
+- [BlueZ](http://www.bluez.org/): Bluetooth connectivity
+
+- [oFono](https://git.kernel.org/pub/scm/network/ofono/ofono.git): telephony
+  and modem management
+
+- [GeoClue](https://gitlab.freedesktop.org/geoclue/geoclue/-/wikis/home):
+  geolocation
+
+Similarly, ongoing work involves expanding various services to expose a
+gRPC interface.
+
+# Application Launcher Service
+
+The Application Framework used to follow the guidelines of the [Desktop Entry
+specification](https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/)
+for application enumeration and start-up, but with the `needlefish` release
+instead it relies on systemd to provide that functionality, indirectly, by
+using the `applaunchd` application.
+
+As no simple reference implementation exists for this part of the
+specification, AGL provides an application launcher service named `applaunchd`.
+This service is part of the default user session, and as such is automatically
+started on session start-up. It can therefore be considered always available.
+
+`applaunchd` enumerates applications installed on the system and provides a
+gRPC interface for services and applications to:
+
+- query the list of available applications
+- request the start-up of a specific application
+- be notified when applications are started or terminated
diff --git a/docs/05_Component_Documentation/Application_Framework/02_Application_Startup.md b/docs/05_Component_Documentation/Application_Framework/02_Application_Startup.md
new file mode 100644
index 0000000..8594426
--- /dev/null
+++ b/docs/05_Component_Documentation/Application_Framework/02_Application_Startup.md
@@ -0,0 +1,248 @@
+---
+title: Application Launcher
+---
+
+# Introduction
+
+At system runtime, it may be necessary for applications to start other
+applications on demand. Such actions can be executed in reaction to a user
+request, or they may be needed to perform a specific task.
+
+In order to do so, running applications and services need an established way of
+discovering installed applications and executing those.
+
+In order to provide a language-independent interface for applications and
+service to use, AGL includes `applaunchd`, a system service.
+
+# Application Launcher Service
+
+The purpose of `applaunchd` is to enumerate applications available on the
+system and provide a way for other applications to query this list and start
+those on demand.  It is also able to notify clients of the start-up and
+termination of applications it manages.
+
+To that effect, `applaunchd` provides a gRPC interface which other applications
+can use in order to execute those actions.
+
+*Note: `applaunchd` will only send notifications for applications it started;
+it isn't aware of applications started by other means (`systemd`, direct
+executable call...), and therefore can't send notifications for those.*
+
+## Application Discovery
+
+Applications are enumerated from systemd's list of available units based on the
+pattern `agl-app*@*.service`, and are started and controled using their systemd
+unit.  Please note `applaunchd` allows only one instance of a given
+application.
+
+## Application Identifiers
+
+Each application is identified by a unique Application ID. Although this ID can
+be any valid string, it is highly recommended to use the "reverse DNS"
+convention in order to avoid potential name collisions.
+
+## gRPC Interface
+
+The interface provides methods for the following actions:
+
+- retrieve the list of available applications
+- request an application to be started
+- subscribe to status events
+
+Moreover, with the gRPC the client subscribes to a status signal to be notified
+when an application has successfully started or its execution terminated.
+
+The gRPC protobuf file provides a Request and Response arguments to RPC methods
+even though in some cases these might be empty in order to allow forward
+compatibility in case additional fields are required.
+It is a good standard practice to follow up with these recommendation when
+developing a new protobuf specification.
+
+### Application Enumeration
+
+The `ListApplications` method allows clients to retrieve the list of available
+applications. 
+
+The `ListRequest` is an empty message, while `ListResponse` contains the following:
+
+```
+message AppInfo {
+  string id = 1;
+  string name = 2;
+  string icon_path = 3;
+}
+
+message ListResponse {
+  repeated AppInfo apps = 1;
+}
+```
+
+### Application Start-up
+
+Applications can be started by using the `StartApplication` method, passing the
+`StartRequest` message, defined as:
+
+```
+message StartRequest {
+  string id = 1;
+}
+```
+
+In reply, the following `StartResponse` will be returned:
+
+```
+message StartResponse {
+  bool status = 1;
+  string message = 2;
+}
+```
+
+The "message" string  of `StartResponse` message will contain an error message
+in case we couldn't start the application for whatever reason, or if the "id"
+isn't a known application ID. The "status" string would be boolean set to
+boolean `TRUE` otherwise.
+
+If the application is already running, `applaunchd` won't start another
+instance, but instead reply with a `AppStatus` message setting the `status`
+string to "started".
+
+### Status Notifications
+
+The gRPC interface provides clients with a subscription model to receive
+status events. Client should subscribe to `GetStatusEvents` method to receive
+them.
+
+The `StatusRequest` is empty, while the `StatusResponse` is defined as
+following:
+
+```
+message AppStatus {
+  string id = 1;
+  string status = 2;
+}
+
+message LauncherStatus {
+}
+
+message StatusResponse {
+  oneof status {
+    AppStatus app = 1;
+    LauncherStatus launcher = 2;
+  }
+}
+```
+
+As mentioned above, the `status` string is set to "started" and is also emitted
+if `applaunchd` receives a request to start an already running application.
+This can be useful, for example, when switching between graphical applications:
+
+- the application switcher doesn't need to track the state of each application;
+  instead, it can simply send a `StartApplication` request to `applaunchd`
+  every time the user requests to switch to another application. Obviously, the
+  client needs to subscribe to get these events and act accordingly.
+- the shell client then receives the `StatusResponse` with the message `status`
+  string set to "started" indicating it that it should activate the window with
+  the corresponding `id` string, or alternatively the string `status` is
+  set to "terminated" to denote that the application has been terminated,
+  forcibly or not
+
+## Start-up, Activation, and Application Switching
+
+Application start-up, activation and application switching are sometimes
+conflated into a single operation but underneath some of these are distinct
+steps, and a bit flaky in some circumstances.
+The [AGL compositor](../02_agl_compositor.md) has
+some additional events which one can use when creating an application
+start-up & switching scheme in different run-times.
+
+Start-up of application is handled entirely by `applaunchd` service while
+activation -- the window which I want to display, but which has never been
+shown, and application switching -- bring forward an application already
+shown/displayed in the past, are operations handled entirely by the
+AGL compositor.
+
+The issue stems from the fact that underneath `applaunchd` can't make any
+guarantees when the application actually started, as it calls into libsystemd
+API to start the specific application systemd unit.
+
+If `StartApplication` can't start the systemd unit, it returns a false
+`status` boolean value and a error message in `StartResponse` message, but if
+the application is indeed started we doesn't really know the *moment* when the
+application is ready to be displayed. Additionally, the AGL compositor
+performed the activation on its own when it detected that a new application
+has been started, but that implicit activation can now be handled outside
+by the desktop run-time/shell client.
+
+*Note: Some of the run-times still rely on the compositor to perform activation
+as this synchronization part between `applaunchd` has not been implemented. The
+plan is to migrate all of remaining run-times to using this approach.*
+
+### Start-up and Activation
+
+This means that we require some sort of interaction between `StartApplication`
+method and the events sent by the AGL compositor in order to correctly handle
+start-up & activation of application.
+
+There are couple of ways of achieving that, either using Wayland native calls,
+or using the gRPC proxy interface, which underneath is using the same Wayland
+native calls.
+
+For the first approach, the AGL compositor has an `app_state` Wayland event
+which contains the application ID, and an enum `app_state` that will propagate
+the following application state events:
+
+```
+<enum name="app_state" since="3">
+  <entry name="started" value="0"/>
+  <entry name="terminated" value="1"/>
+  <entry name="activated" value="2"/>
+  <entry name="deactivated" value="3"/>
+</enum>
+```
+
+The `started` event can be used in correlation with the `StartApplication`
+method from `applaunchd` such that upon received the `started` even, it can
+explicitly activate that particular appid in order for the compositor to
+display it. See [AGL compositor](../02_agl_compositor.md)
+about how activation should be handled.
+
+*Note: These can only be received if by the client shell which binds to the
+agl_shell interface*.
+
+Alternatively, when using the gRPC proxy one can register to receive these
+status events similar to the `applaunchd` events, subscribing to
+`AppStatusState` method from the grpc-proxy helper application, which has the
+following protobuf messages:
+
+```
+message AppStateRequest {
+}
+message AppStateResponse {
+        int32 state = 1;
+        string app_id = 2;
+}
+```
+
+The integer state maps to the `enum app_state` from the Wayland protocol, so
+they are a 1:1 match.
+
+Here's the state diagram for the Qt homescreen implementation of the
+application start-up:
+
+![Application_start](images/start_and_activation.png)
+
+### Application Switching
+
+With the compositor providing application status events, it might seem that the
+`applaunchd`'s, `GetStatusEvents` might be redundant, but in fact it is being
+used to perform application switching. The run-time/shell client would in fact
+subscribe to `GetStatusEvents` and each application wanting to switch to another
+application would basically call `StartApplication`. That would eventually reach
+the run-time/shell-client and have a handler that would ultimately activate the
+application ID.
+
+![Application_switching](images/application_switching.png)
+
+*Note: In practice, the run-time/shell-client would subscribe to both `applaunchd`
+and to the AGL compositor, either Wayland native events, or using the gPRC-proxy
+helper client, although the diagrams show them partly decoupled*.
diff --git a/docs/05_Component_Documentation/Application_Framework/03_Creating_a_New_Application.md b/docs/05_Component_Documentation/Application_Framework/03_Creating_a_New_Application.md
new file mode 100644
index 0000000..aa528b1
--- /dev/null
+++ b/docs/05_Component_Documentation/Application_Framework/03_Creating_a_New_Application.md
@@ -0,0 +1,233 @@
+---
+title: Creating a New Application
+---
+
+In the context of AGL, "applications" are usually considered to be standalone
+user facing infotainment applications that can be started in addition to the
+default "homescreen" or similar user interface that will always be present.
+Such applications can be enumerated and executed with `applaunchd`, the AGL
+[application launcher service](02_Application_Startup.md).  The following
+sections walk through what is required to add an application to an AGL image
+that uses applaunchd, as well as discussion of developer conveniences that
+AGL provides to simplify doing so in the Yocto build environment.
+
+# Basic Requirements
+
+As described in the [applaunchd documentation](02_Application_Startup.md#application-discovery),
+applications need to have a systemd system unit with a name matching the pattern `agl-app*@*.service`.
+The portion of the unit name between `@` and `.service` is used as the application identifier
+(see [Application Identifiers](02_Application_Startup.md#application-identifiers)).
+The use of `@` in the unit filename indicates the use of a template unit, which `applaunchd`
+assumes will be used for applications (see below). Template unit files are discussed in the
+systemd unit file [man page](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description).
+
+The requirements on the unit file contents are:
+
+- The `Description` field is used as the desired display name of the application.
+  It is recommended that this be kept short, ideally to one or two words, in order to
+  avoid issues when applications are listed in a UI.
+- While not a hard requirement, ideally the `User` field is used to specify running
+  the application as a non-privileged user. In the AGL demonstration images, the
+  `agl-driver` user is used.
+
+Blah blah icon...
+
+# Graphical Application Requirements
+
+In addition, graphical applications need to comply with a few more requirements:
+
+1. Each application must set a Wayland application ID appropriately as soon as its main window
+is created.
+2. The `app-id` used must match the application identifier specified in the systemd unit filename.
+
+Doing so will ensure other software can associate the actual `app-id` to the proper application.
+
+*Note: application ID's are set using the [XDG toplevel](https://wayland-book.com/xdg-shell-basics/xdg-toplevel.html)
+Wayland interface.*
+
+# Application Templates
+
+To provide a working example of application template units, AGL includes templates
+for generic, Flutter, and web applications as part of the `applaunchd` recipe in the
+`meta-app-framework` layer in [meta-agl](../../04_Developer_Guides/02_AGL_Layers/02_meta_agl.md).
+If applaunchd is built into an image using the recipe, these templates will be available
+for applications to use for their systemd units by creating a symlink that includes the
+application identifier.  To simplify this, a `BitBake` class named `agl-app` is included in
+the layer for use in application recipes.  The different templates and their configuration
+will be discussed further in the following sections.
+
+## Generic Graphical Application Template
+
+The `agl-app@.service` template unit is intended for simple standalone graphical applications.
+It makes the following assumptions by default:
+
+- The application executable name is the same as the application identifier, and the
+  executable is available via the default `PATH`.
+- The application `Description` will be the application identifier.
+- The application should run as the `agl-driver` user.
+
+If using the `agl-app` class in a recipe (with `inherit agl-app`), these defaults can be
+changed via the variables:
+
+- `AGL_APP_NAME`: overrides the value of the `Description` field to set the desired
+  application display name.
+- `AGL_APP_EXEC`: overrides the application executable name.
+
+If set, these variables will trigger the generation of one or more systemd `drop-in`
+override files by the logic in the `agl-app` class.  The use of `drop-in` configuration
+files is discussed in the systemd unit file [man page](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description).
+
+Additionally, the variable `AGL_APP_ID` may be used to override the assumption that the
+application identifier is the same as the recipe name. If specified, its value should be
+the desired application identifier.
+
+The following is a partial example BitBake recipe using the template for an application named
+`foo`:
+
+```text
+
+SUMMARY = "foo application"
+HOMEPAGE = "https://git.automotivelinux.org/apps/foo"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=ae6497158920d9524cf208c09cc4c984"
+
+PV = "1.0+git${SRCREV}"
+
+SRC_URI = "git://git.automotivelinux.org/apps/foo;protocol=https;branch=master"
+SRCREV = "abcdef012"
+
+S = "${WORKDIR}/git"
+
+inherit agl-app
+
+AGL_APP_NAME = "Foo"
+
+<Other application build configuration>
+```
+
+Note that this assumes that the recipe is named `foo_git.bb`. If the recipe was instead named
+something like `foo-app_git.bb`, then `AGL_APP_ID = "foo"` would need to be added.
+
+## Flutter Application Template
+
+The `agl-app-flutter@.service` template unit is intended for Flutter graphical applications
+that use the `flutter-auto` Flutter embedder.  It makes the following assumptions by default:
+
+- The Flutter application name in `pubspec.yaml` is the same as the application identifier,
+and the application bundle will be installed under the directory:
+  ```text
+  /usr/share/flutter/<application identifier>/<Flutter version>/<Flutter runtime type>
+  ```
+  For example:
+  ```text
+  /usr/share/flutter/flutter_hvac/3.3.7/release
+  ```
+
+- The application `Description` will be the application identifier.
+- The application should run as the `agl-driver` user.
+
+If using the `agl-app` class in a recipe (with `inherit agl-app`), the use of the Flutter
+template can be triggered by setting the variable `AGL_APP_TEMPLATE` to `agl-app-flutter`,
+and the above defaults can be changed via the variables:
+
+- `AGL_APP_NAME`: overrides the value of the `Description` field to set the desired
+  application display name.
+
+If set, this will trigger the generation of a systemd `drop-in` override file by the logic
+in the `agl-app` class.  The use of `drop-in` configuration files is discussed in the systemd
+unit file [man page](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description).
+
+Additionally, the variable `AGL_APP_ID` may be used to override the assumption that the
+application identifier is the same as the recipe name. If specified, its value should be
+the desired application identifier and Flutter application / bundle name.
+
+The following is an example BitBake recipe using the template for a Flutter application
+named `foo`:
+
+```text
+
+SUMMARY = "Flutter foo application"
+HOMEPAGE = "https://git.automotivelinux.org/apps/flutter-foo"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://License.md;md5=f712ede8d4f845976061925d1416fc40"
+
+PV = "1.0+git${SRCREV}"
+
+SRC_URI = "git://git.automotivelinux.org/apps/flutter-foo;protocol=https;branch=master"
+SRCREV = "abcdef012"
+
+S = "${WORKDIR}/git"
+
+inherit flutter-app agl-app
+
+PUBSPEC_APPNAME = "foo"
+FLUTTER_APPLICATION_INSTALL_PREFIX = "/flutter"
+
+AGL_APP_TEMPLATE = "agl-app-flutter"
+AGL_APP_NAME = "Foo"
+```
+
+Note that this assumes that the recipe is named `foo_git.bb`, and that the application name
+in the Flutter `pubspec.yaml` is `foo`.  If the recipe was instead named something like
+`flutter-foo_git.bb`, then `AGL_APP_ID = "foo"` would need to be added.
+
+## Web Application Template
+
+The `agl-app-web@.service` template unit is intended for web applications run using the
+Web Application Manager (WAM) service.  It makes the following assumptions by default:
+
+- The web application bundle directory name is the same as the application identifier, and the
+  bundle will be installed in the directory hierarchy:
+  ```
+  /usr/lib/wam_apps/<application identifier>
+  ```
+  For example:
+  ```
+  /usr/lib/wam_apps/webapps-hvac
+  ```
+- The application `Description` will be the application identifier.
+- The application should run as the `agl-driver` user.
+
+If using the `agl-app` class in a recipe (with `inherit agl-app`), the use of the Flutter
+template can be triggered by setting the variable `AGL_APP_TEMPLATE` to `agl-app-web`,
+and the above defaults can be changed via the variables:
+
+- `AGL_APP_NAME`: overrides the value of the `Description` field to set the desired
+  application display name.
+- `AGL_APP_WAM_DIR`: overrides the application bundle directory name. This can be used if
+  the application bundle name does not match the application identifier.
+
+If set, these variables will trigger the generation of one or more systemd `drop-in`
+override files by the logic in the `agl-app` class.  The use of `drop-in` configuration
+files is discussed in the systemd unit file [man page](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description).
+
+Additionally, the variable `AGL_APP_ID` may be used to override the assumption that the
+application identifier is the same as the recipe name.
+
+The following is a partial example BitBake recipe using the template for a web application
+named `foo`:
+
+```text
+
+SUMMARY = "Web foo application"
+HOMEPAGE = "https://git.automotivelinux.org/apps/web-foo"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
+
+PV = "1.0+git${SRCREV}"
+
+SRC_URI = "git://git.automotivelinux.org/apps/web-foo;protocol=https;branch=master"
+SRCREV = "abcdef012"
+
+S = "${WORKDIR}/git"
+
+inherit agl-app
+
+AGL_APP_TEMPLATE = "agl-app-web"
+AGL_APP_NAME = "Foo"
+
+<Other web application build configuration>
+```
+
+Note that this assumes that the recipe is named `foo_git.bb`. If the recipe was instead named
+something like `foo-web_git.bb`, then `AGL_APP_ID = "foo"` would need to be added.
diff --git a/docs/05_Component_Documentation/Application_Framework/04_Application_Sandboxing.md b/docs/05_Component_Documentation/Application_Framework/04_Application_Sandboxing.md
new file mode 100644
index 0000000..356c0eb
--- /dev/null
+++ b/docs/05_Component_Documentation/Application_Framework/04_Application_Sandboxing.md
@@ -0,0 +1,92 @@
+---
+title: Application Sandboxing
+---
+
+One of the motivations for leveraging systemd in `applaunchd` was to allow the use of its
+advanced features such as [sandboxing](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxing),
+[system call filtering](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#System%20Call%20Filtering),
+[process limits](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%20Properties), and
+Linux CGroup configuration via [slices](https://www.freedesktop.org/software/systemd/man/systemd.slice.html).
+The scope of potential systemd configurations involving these options is broad, and so far AGL has focused on providing
+some simple examples of basic sandboxing integrated with the application templates discussed above.
+
+## Network Access Restriction
+
+The systemd [`PrivateNetwork`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateNetwork=)
+service configuration option can be used to disable network access for the service started by a unit file.
+The `applaunchd` packaging installs a systemd drop-in configuration file named `no-network.conf` in the
+directory `/usr/lib/systemd/system/sandboxing` that may be used to disable network access with `PrivateNetwork`.
+To use it, `no-network.conf` should be symlinked in an appropriate unit file drop-in override directory per
+systemd naming expectations (see systemd unit file
+[man page](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description)).
+The following is a `BitBake` recipe snippet showing installation of the drop-in for an application named `foo`
+that is using the generic application template:
+
+```text
+...
+
+inherit agl-app
+
+AGL_APP_NAME = "Foo"
+
+do_install() {
+    # Enable systemd sandboxing override as a demonstration
+    install -d ${D}${systemd_system_unitdir}/agl-app@${AGL_APP_ID}.service.d/
+    ln -sf ${systemd_system_unitdir}/sandboxing/no-network.conf ${D}${systemd_system_unitdir}/agl-app@${AGL_APP_ID}.service.d/
+}
+
+FILES:${PN} = " \
+    ${sysconfdir}/systemd/system/agl-app@${AGL_APP_ID}.service.d \
+"
+
+...
+```
+
+This results in a `/usr/lib/systemd/system/agl-app@foo.service.d/no-network.conf` symlink being created
+in the `foo` packaging, disabling network access when `foo` is started by `applaunchd` or directly via
+`systemctl` on the command line.
+
+## Private Temporary Directories
+
+The systemd [`PrivateTmp`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=)
+service configuration option can be used to prevent access to the host `/tmp` and `/var/tmp` directories
+for the service started by a unit file.  The service will instead have private temporary mounts of these
+directories in a new mount namespace.  The `applaunchd` packaging installs a systemd drop-in configuration
+file named `private-tmp.conf` in the directory `/usr/lib/systemd/system/sandboxing` that may be used to
+create private temporary directory mounts with `PrivateTmp`. To use it, `private-tmp.conf` should be
+symlinked in an appropriate unit file drop-in override directory per systemd naming expectations (see
+systemd unit file [man page](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description)).
+See above for an example `BitBake` recipe snippet showing installation of a drop-in file when using the
+generic application template.
+
+## Other Sandboxing Options
+
+In addition to the above, some other notable systemd sandbox options worth further consideration for
+applications include:
+
+- [PrivateDevices](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateDevices=)  
+  This option could be used to remove access to device files in /dev for applications that do not
+  require them, but it is likely that `DeviceAllow` may also need to be used to enable functionality in
+  some applications.
+- [ProtectSystem](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=)  
+  The default and `full` modes of this option likely can be enabled with little impact to most
+  applications, as they should not need write access to the directories that are made read-only.
+  Using the `strict` option would need investigation into interactions with usage of directory
+  hierarchies like `/run`.
+- [ProtectHome](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome=)  
+  This option seems worthwhile if the system ends up with more than one active user for running
+  applications, but interactions with default application caching and configuration locations
+  needs to be investigated.  It is likely that enforcing use of locations outside of `/home`
+  for these would need to be settled upon and documented for application developers.  For
+  example using the [XDG directory scheme](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)
+  similar to the previous AGL application framework.
+- [ReadWritePaths, etc.](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths=)  
+   These options provide a more fine-grained approach to some of the above ones, and could be
+   used to enable something like an application only seeing its own files and the contents of
+   a specific set of directories like `/etc` and `/usr/lib`.  Implementing such would likely
+   require settling on a custom application installation hierarchy as was done in the previous
+   AGL application framework.
+
+The above list is not exhaustive, and does not include some other likely possibilities involving
+system call filtering and resource limits.  Future AGL releases may expand the examples provided
+with `applaunchd` along these lines.
diff --git a/docs/05_Component_Documentation/Application_Framework/images/application_switching.msc b/docs/05_Component_Documentation/Application_Framework/images/application_switching.msc
new file mode 100755
index 0000000..ceeab7c
--- /dev/null
+++ b/docs/05_Component_Documentation/Application_Framework/images/application_switching.msc
@@ -0,0 +1,29 @@
+#!/usr/bin/mscgen -Tpng
+
+msc {
+       hscale="1.5";
+
+       u [label = "touch/pointer event" ],
+       l [label = "launcher app" ],
+       s [label = "runtime/shell-client"],
+       a [label = "applaunchd" ],
+       g [label = "gRPC-proxy" ],
+       c [label = "compositor" ],
+       d [label = "libsystemd"];
+
+       |||;
+
+       --- [label = "initial phase - subscribe for signal/status events, assume app_id already started" ];
+
+       s >> a [label = "subscribe for applaunchd GetStatusEvents"];
+
+       --- [label = "handling of application switching" ];
+
+       u => l [label = "tapShortCut(appid)" ];
+       l => a [label = "StartApplication(appid)"];
+       a => d [label = "start application's systemd unit"];
+       d => a [label = "return status from starting systemd unit"];
+       a => s [label = "StartResponse(status = TRUE)"];
+       a => s [label = "StatusResponse(app_id, 'started')"];
+       s => c [label = "activate_app(app_id)"];
+}
diff --git a/docs/05_Component_Documentation/Application_Framework/images/application_switching.png b/docs/05_Component_Documentation/Application_Framework/images/application_switching.png
new file mode 100644
index 0000000..0b5584a
--- /dev/null
+++ b/docs/05_Component_Documentation/Application_Framework/images/application_switching.png
diff --git a/docs/05_Component_Documentation/Application_Framework/images/start_and_activation.msc b/docs/05_Component_Documentation/Application_Framework/images/start_and_activation.msc
new file mode 100755
index 0000000..d835f8b
--- /dev/null
+++ b/docs/05_Component_Documentation/Application_Framework/images/start_and_activation.msc
@@ -0,0 +1,30 @@
+#!/usr/bin/mscgen -Tpng
+
+msc {
+       hscale="1.5";
+
+       u [label = "touch/pointer event" ],
+       s [label = "runtime/shell-client"],
+       a [label = "applaunchd" ],
+       g [label = "gRPC-proxy" ],
+       c [label = "compositor" ],
+       d [label = "libsystemd"];
+
+       |||;
+
+       --- [label = "initial phase - subscribe for signal/status events" ];
+
+       s >> g [label = "subscribe for AGL compositor AppStatusState"];
+       g >> c [label = "listen for app_state Wayland events"];
+
+       --- [label = "handling start-up & activation" ];
+
+       u => s [label = "tapShortCut(appid)" ];
+       s => a [label = "StartApplication(appid)"];
+       a => d [label = "start application's systemd unit"];
+       d => a [label = "return status from starting systemd unit"];
+       a => s [label = "StartResponse(status = TRUE)"];
+       c => g [label = "app_state(app_state = APP_STARTED)"];
+       g => s [label = "AppStatusResponse(app_id, APP_STARTED)"];
+       s => c [label = "activate_app(app_id)"];
+}
diff --git a/docs/05_Component_Documentation/Application_Framework/images/start_and_activation.png b/docs/05_Component_Documentation/Application_Framework/images/start_and_activation.png
new file mode 100644
index 0000000..593fc0e
--- /dev/null
+++ b/docs/05_Component_Documentation/Application_Framework/images/start_and_activation.png
diff --git a/docs/05_Component_Documentation/Demo_Application/01_Momi_Navi.md b/docs/05_Component_Documentation/Demo_Application/01_Momi_Navi.md
new file mode 100644
index 0000000..ac0f886
--- /dev/null
+++ b/docs/05_Component_Documentation/Demo_Application/01_Momi_Navi.md
@@ -0,0 +1,35 @@
+---
+title: Momi Navi
+---
+
+# What is Momi Navi
+
+Momi Navi is a example application for navigation.  It run on simple ivi demo (that name is momi IVI) for the instrument cluster container integration.
+
+![](images/mominavi.jpg)
+
+## How to use
+
+When you build the instrument cluster integration without momi navi specific setting, it will not show map.  You need momi navi specific setting.
+
+The momi navi uses mapbox gl plugin fo Qt location.  It requires own access token to download map.  You can create own mapbox access token following [this page](https://docs.mapbox.com/help/getting-started/access-tokens/).
+
+After creation, please set environment variable to local.conf (or site.conf).
+
+```
+MOMIMAP_MAPBOX_ACCESS_TOKEN = "Your access token."
+```
+
+## Extra configuration
+
+Momi navi supports configuration for customize.
+
+When you set environment variable to local.conf (or site.conf), you can customize Momi navi.
+
+| Environment variable | Customizing parametor |
+|:---|:---|
+| MOMIMAP_MAPBOX_STYLE | Map style |
+| MOMIMAP_INITIAL_LATITUDE | Default location |
+| MOMIMAP_INITIAL_LONGITUDE | Default location |
+
+How to create map style, please check [this page](https://docs.mapbox.com/studio-manual/guides/map-styling/).
diff --git a/docs/05_Component_Documentation/Demo_Application/images/mominavi.jpg b/docs/05_Component_Documentation/Demo_Application/images/mominavi.jpg
new file mode 100644
index 0000000..8e30c05
--- /dev/null
+++ b/docs/05_Component_Documentation/Demo_Application/images/mominavi.jpg
diff --git a/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/Application-Logic.png b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/Application-Logic.png
new file mode 100644
index 0000000..de3c4eb
--- /dev/null
+++ b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/Application-Logic.png
diff --git a/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/Dashboard.png b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/Dashboard.png
new file mode 100644
index 0000000..e31024e
--- /dev/null
+++ b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/Dashboard.png
diff --git a/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/HVAC.png b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/HVAC.png
new file mode 100644
index 0000000..c4db3b2
--- /dev/null
+++ b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/HVAC.png
diff --git a/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/IC.png b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/IC.png
new file mode 100644
index 0000000..72555dc
--- /dev/null
+++ b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/IC.png
diff --git a/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/SC.png b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/SC.png
new file mode 100644
index 0000000..4e3ec84
--- /dev/null
+++ b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/SC.png
diff --git a/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/Settings_Page.png b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/Settings_Page.png
new file mode 100644
index 0000000..2812a8d
--- /dev/null
+++ b/docs/05_Component_Documentation/images/AGL-Demo-Control-Panel/Settings_Page.png
diff --git a/docs/05_Component_Documentation/images/Unified-HMI/RVGPU_Architecture.png b/docs/05_Component_Documentation/images/Unified-HMI/RVGPU_Architecture.png
new file mode 100755
index 0000000..bdefbf5
--- /dev/null
+++ b/docs/05_Component_Documentation/images/Unified-HMI/RVGPU_Architecture.png
diff --git a/docs/05_Component_Documentation/images/Unified-HMI/Using_RVGPU_from_Ubuntu_to_AGL.png b/docs/05_Component_Documentation/images/Unified-HMI/Using_RVGPU_from_Ubuntu_to_AGL.png
new file mode 100755
index 0000000..d187bee
--- /dev/null
+++ b/docs/05_Component_Documentation/images/Unified-HMI/Using_RVGPU_from_Ubuntu_to_AGL.png
diff --git a/docs/05_Component_Documentation/images/agl-compositor/arch_diagram.png b/docs/05_Component_Documentation/images/agl-compositor/arch_diagram.png
new file mode 100644
index 0000000..88a4381
--- /dev/null
+++ b/docs/05_Component_Documentation/images/agl-compositor/arch_diagram.png
diff --git a/docs/05_Component_Documentation/images/agl-compositor/drawing_shell.png b/docs/05_Component_Documentation/images/agl-compositor/drawing_shell.png
new file mode 100644
index 0000000..bcd0a98
--- /dev/null
+++ b/docs/05_Component_Documentation/images/agl-compositor/drawing_shell.png
diff --git a/docs/05_Component_Documentation/images/agl-voice-agent/AGL_Offline_VoiceAgent_(High_Level_Architecture).png b/docs/05_Component_Documentation/images/agl-voice-agent/AGL_Offline_VoiceAgent_(High_Level_Architecture).png
new file mode 100644
index 0000000..3627fbf
--- /dev/null
+++ b/docs/05_Component_Documentation/images/agl-voice-agent/AGL_Offline_VoiceAgent_(High_Level_Architecture).png
diff --git a/docs/05_Component_Documentation/images/agl-voice-agent/voice-assistant-flutter-1.png b/docs/05_Component_Documentation/images/agl-voice-agent/voice-assistant-flutter-1.png
new file mode 100644
index 0000000..feadd9c
--- /dev/null
+++ b/docs/05_Component_Documentation/images/agl-voice-agent/voice-assistant-flutter-1.png
diff --git a/docs/05_Component_Documentation/images/agl-voice-agent/voice-assistant-flutter-2.png b/docs/05_Component_Documentation/images/agl-voice-agent/voice-assistant-flutter-2.png
new file mode 100644
index 0000000..010535b
--- /dev/null
+++ b/docs/05_Component_Documentation/images/agl-voice-agent/voice-assistant-flutter-2.png
diff --git a/docs/05_Component_Documentation/images/ic-sound-manager/architecture.png b/docs/05_Component_Documentation/images/ic-sound-manager/architecture.png
new file mode 100644
index 0000000..3d0820f
--- /dev/null
+++ b/docs/05_Component_Documentation/images/ic-sound-manager/architecture.png
diff --git a/docs/05_Component_Documentation/images/ic-sound-manager/pipewire-ic-ipc-calls.png b/docs/05_Component_Documentation/images/ic-sound-manager/pipewire-ic-ipc-calls.png
new file mode 100644
index 0000000..9003e60
--- /dev/null
+++ b/docs/05_Component_Documentation/images/ic-sound-manager/pipewire-ic-ipc-calls.png
diff --git a/docs/05_Component_Documentation/images/ic-sound-manager/pipewire-ic-ipc-processes.png b/docs/05_Component_Documentation/images/ic-sound-manager/pipewire-ic-ipc-processes.png
new file mode 100644
index 0000000..494b760
--- /dev/null
+++ b/docs/05_Component_Documentation/images/ic-sound-manager/pipewire-ic-ipc-processes.png
diff --git a/docs/05_Component_Documentation/images/rba/Basic_syntax.png b/docs/05_Component_Documentation/images/rba/Basic_syntax.png
new file mode 100644
index 0000000..6704abd
--- /dev/null
+++ b/docs/05_Component_Documentation/images/rba/Basic_syntax.png
diff --git a/docs/05_Component_Documentation/images/rba/model.png b/docs/05_Component_Documentation/images/rba/model.png
new file mode 100644
index 0000000..e43289e
--- /dev/null
+++ b/docs/05_Component_Documentation/images/rba/model.png