Page History

...

reference

...

Architecture

Below is a more detailed diagram with technical components inside the RDK6.1 SW on STB and DAC reference cloud

...

The OCI registry is the binary App exchange point between App developer and consuming parties/operators for distribution of the App on their target platforms.

...

DAC Cloud

...

To support the STB components, backend/cloud infrastructure has been developed. These components allow operators to create application submission portals where developers can submit their applications and their corresponding metadata. These submitted applications can then be converted from an OCI image to an OCI bundle ready for use on an operator's specific hardware.

The AppStore Metadata Service (ASMS) component provides APIs for both a developer and an STB to use to upload application metadata and search for previously uploaded applications. More documentation on ASMS can be found here: App Store Metadata Service (ASMS)

The BundleGen tool is a command-line tool that runs in the cloud to prepare containers for use on specific platforms. It uses template files created by an operator to ensure that the container is configured appropriately for the specific hardware requirements of an operators STB. This includes but is not limited to graphics libraries, sockets, IPC and network configuration. More detailed documentation for BundleGen can be found here: BundleGen

...

reference

To run the oci compliant AppContainer on set of devices in production, an associated secure distribution solution/system must be in place.
This distribution solution is responsibility of the operator and not of the app developer. 
It is typically also a distribution system / instance per operator/environment because: 

• the operator needs to be in control of what apps are made available on what environment. The available App may have to be different per country, different in test vs prod environment
• and operators will likely have different keysets per distribution system/instance for security reasons.

RDK provides a reference distribution solution, see the "DAC cloud reference" as depicted in reference architecture diagram above. It consists out of several µservices. If you hover over the specific µservice on the diagram you can see the link to its associated open source code. 

RDK and RDK-M do not mandate use of a particular distribution solution towards the RDK operators. 
The operators are free to choose, make/buy their secure distribution solution. Some operator choose to build further on system they already had, some operators are using their instance of the DAC cloud reference.
As long as the operator distribution system can take in the oci, dac compliant AppContainer, securely distribute and convert it to its OCI bundle equivalent ready for use on the operator specific CPE devices that support the dac contract for binary compatibility, it should be fine. In future we may want to validate this as part of firebolt certification of those devices.

RDK-M does operate an instance of the reference DAC cloud that serves an AppCatalog with DAC Appcontainers for all the RDK-M Video Accelerators
It is important staging, test and reference environment for App developers and RDK community, allowing App developers to publish their DAC native apps and test/run them on all the RDK Video Accelerators with a RDK6.1 software image (from 3 different SoC vendors).
Without such environment App developers cannot test and run their Application on real devices and that is obviously not acceptable.
If RDK-M organizes certification testing of a native Application, it will tested/certify against this environment
Operators will want to see the application successfully running and passing testing on this DAC Video accelerator environment before starting testing of the same app on their environment and boxes.

To be able to install and run the AppContainer on set of target devices/population following things are required:
The reference DAC cloud solution has been designed to fulfill those requirements.

• The application must be made discoverable in some form of appcatalog available to those target devices. System is needed that allows you to register, add applications with appropriate metadata to that AppCatalog but also allows the consuming devices to browse that appcatalog and have all the information needed to securely install particular application and once installed be able to run it. For that the Appstore Metadata µService (ASMS) has been created. It provides restful API (swagger/open API).  See more information in following wiki page on how to use the ASMS API   
• The Appcontainer in the OCI image format needs to be transformed to so called "bundle" format to be able to load/run it on real host. Such bundle consists out of the final filesystem of the container (is result of possibly more than one file system layers specified in OCI image format spec) and a "run" time "config.json" so it can be run on a host with OCI runtime like crun. One can also say that bundle is Container rootfs + run config.json" 
  See the oci runtime specification for bundle term definition and run time "config.json" parameters.
  The "run" config.json is the Container configuration. It is the responsibility of the distributor/operator, not the application provider to configure this.
  The operator will for example configure/constrain Linux capabilities of the container for security reasons. The "run" config also contains few platform specific bind mounts (STB model, can be firmware specific) from host rootfs to AppContainer rootfs (like bind mount of SoC specific Graphics libraries that implement libGLESv2 & libEGL) as well as bind mounts of few unix domain sockets (socket of waylandserver & rialtoserver instance) required to interface with the defined abstraction layers for Graphics and Audio/Video/DRM. The run "config.json" takes some parameters from oci image config that are needed in run config (such as launch point/path of the application within the container)

In the architecture diagram you can find the bundle generator µservice  that will upon RabbitMQ trigger automatically generate from an OCI image the appropriate OCI bundle for specific HWmodel (VA) and store it for downstream usage. It will use the appropriate config template for that associated HWmodel (see example HWmodel specific templates here ) for generation of the run config.json. The bundlegen code that the µservice is executing during this bundlegeneration of an app is located here.  

• We must be able to secure bundles:  both integrity and content confidentiality of bundle (config.json + rootfs) must be ensured during distribution and when installed on target device. That is ensuring bundle config.json and container filesystem cannot be changed by hackers after the generation by operator/distributor, during distribution nor when stored/installed on the device.

In the architecture diagram you can find the bundle cryptor µservice that will upon generation of new bundle by bundlegeneration service, sign and encrypt the bundle. For more information on that we refer to DAC session at Technology Summit 2023#pane-uid-b13cbeba-87dc-4f0a-9932-5b7e00770663-1 

...

and documentation on access restricted page DAC Security 

• The system should automatically generate and secure bundles for the various platforms, doing this manually does not scale.

That is what the system is doing. Once bundle for particular app_id/platform/compatible version is created, it will be available in ASCS (Appstore Caching service) (which cab serve as origin for higher scale caching on CDN). If you request bundle for particular app_id/platform/compatibleversion towards ASCS and if it is not available in its cache it will automatically trigger real time creation of associated bundle in a flow managed by ASBS (appstore bundle service). ASBS will fetch appropriate metadata from ASMS and give instructions with right input parameters to respectively bundle-generator-service and bundle-cryptor-service via RabbitMQ to generate and secure the bundle and cache on ASCS. 

STB / CPE

DAC provides all the necessary tooling to run containerised applications using OCI containers on an RDK-V STB. The main component of this is Dobby, an embedded-focused OCI container manager. Dobby is used to start, stop and monitor containers running on a STB, using the crun runtime underneath to interface with the kernel and start the containers. Dobby is written in C++ and designed to have minimal footprint and performance impact. The OCIContainer Thunder plugin allows for interfacing with Dobby using a JSON-RPC interface, and Dobby can also be used to run other Thunder plugins in containers using the ProcessContainer backend.

...