RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
...
Multimedia name dac_overview_rdk_tech_summit_2024_1080p.mp4
...
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.
...
...
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
...
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:
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.
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.
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
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.
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.
...