Version Details

Pre-requisites

Vendor is expected to meet certain prerequisites before proceeding to the integration process, which includes:

• RDK device profile:
  • Decide which device profile by referring to the available RDK profiles and have a platform with expected capabilities for the chosen profile. Depending on the device profile selected, the components that are required to be ported are available at HAL section in Vendor porting guide .
• Platform with certified RDK Port:
  • A SOC platform with a certified RDK port on it. Please note that the RDK Port certification satisfies only the availability of RDK and not any third-party software, which is expected in most video devices nowadays, which a SOC should be supporting on a platform. A list of SOC reference platforms on which the RDK6 release is certified is available here .
    
• Product feature details:

• • While this is an obvious requirement, a detailed product requirement helps to identify which additional software integrations and implementations are required, as well as their associated tests and certifications. A sample list for reference is available as part of the RDK Video Accelerator platform product specification at here .

Porting

Environment:

Yocto-based build environment(highly recommended) :

RDK uses the Yocto Bitbake build system to generate RDK builds. The flexibility of Yocto to add or remove components or layers with much ease helps to keep RDK working fine with multiple sets of SoC, OEM, operator, and third-party software combinations. Using Yocto as the build environment will help the integrators easily plug in RDK and third-party software stacks, thereby reducing integration efforts. There would be a basic RDK build system on which SoC could add their Soc layer, OEM could add their OEM layer, and finally Operator could add their Operator layer (and any third-party software stacks by any of these parties). The starting point for the Yocto build is a manifest file. For more details, please refer to the manifest file .

Steps to setup a Yocto-based build environment is detailed below:

Host Setup Details

For host setup details, refer to this link: Build Setup Instructions

Initializing the build environment

While the actual build setup depends on how the vendor wants to set it up, a sample Yocto build system for the RDK generic reference platforms is given below as a reference:

mkdir <workspace>
cd <workspace>    
 
repo init -u https://code.rdkcentral.com/r/manifests -b 6.0.0 -m rdkv.xml
repo sync --no-clone-bundle --no-tags 

Add the vendor layer in Yocto

• Click here to understand and create layers.
• Refer to this link to know about the RDK Yocto Layer Structure.

Integrator specific build environment:

Integrators can use build framework of their choice to create the software for their platform. This will help them to use their existing build framework and proceed with development. As this framework varies from vendor to vendor (for example, Buildroot), there are no generic steps that can be shared towards this. However, this is highly discouraged as RDK, by default, comes with the Yocto build framework (above option), which helps in seamless integration of multiple layers (SOC, device, OEM, third party, operator) and easier upgrades with fewer dependencies on other parties.

For FAQs on Yocto Build, please refer to the Build FAQ .

Device Security

There are many security features in the RDK, and the three major features of the platform are containerization, access control, and kernel hardening. 

• Containerization is a mechanism to achieve process isolation by running a limited set of applications or services within a self-contained, sandboxed environment. It is a mechanism for sandboxing processes (isolating processes from each other) by using some kernel features. 
• Access control refers to the security principle that all software processes should run with the minimum privileges needed for them to operate. A process should only have access to the data, files, interfaces, and capabilities that it needs and should not have access to data owned by other processes or other parts of the system. Processes should not run with root privileges unless absolutely required. Access control can be achieved through security module hooks in the kernel, which verify whether the user or process has access to the requested resource on each system call. Using such a standard implementation improves the scalability of the stack. One such example is AppArmor.
• Kernel hardening refers to the process of strengthening the security of the operating system kernel by applying various techniques, configurations, and security measures. The goal is to decrease vulnerabilities, eliminate risks, and strengthen the kernel to prevent attacks.

Third-Party Software Stack Integration

When integrating external components into the hardware deployment, it is crucial to adhere to the standard integration procedures. Any required third-party software should be integrated using the appropriate mechanisms provided by the RDK.

For instance, when integrating tuner support or any other external component, the recommended approach is to bring it in as a Thunder plugin or an RDK service. Thunder plugins and RDK services provide a standardized and modular way to incorporate additional functionalities into the RDK framework. By utilizing these mechanisms, the external component can seamlessly integrate and interact with the RDK infrastructure.

Similarly, for DRM (Digital Rights Management) functionality, the preferred method is to bring in the necessary DRM plugin as an OpenCDM (Open Content Decryption Module) plugin. OpenCDM is a plugin framework that enables the integration of various DRM technologies into the RDK ecosystem. Popular DRM solutions like PlayReady and Widevine are already part of the DRM implementation from various SoC providers.

Apps

Ripple, a reference implementation of the Firebolt API specification, is a Rust-based application gateway supporting dynamic extension loading. It will offer a Firebolt Gateway for Distributors and App Developers to engage with the Application platform, facilitating the discovery, launch, and management of applications. RDK supports an app database called Firebolt Connect. Firebolt Connect is a single source of truth for applications. Vendors have to provide bundling and encryption on top of that to make it useful.

From the API side, below are the mandatory APIs to have your app Firebolt certified:

Starting up your app

The first thing your app will want to do is tell Firebolt that it's ready. Firebolt avoids assuming your app is minimally usable and gives you complete control over when your app is ready to be presented to end users.  When you have rendered enough of your app just call “ready”. That's it! Now Firebolt knows that it's safe to present your app to end users, and can do so as quickly as possible. It's recommended to also listen to any Firebolt events before calling ready, to ensure you don't miss any.

Click here for more details about app development and refer to Firebolt APIs that help to build apps for RDK-powered connected home devices and reach millions.

Peripheral Device

Third-party vendors, operators, and system integrators can seamlessly integrate peripheral devices such as remote controls and other accessories into the RDK box. Integrating peripheral devices such as remote controls with the RDK box involves ensuring compatibility, connecting the device to appropriate ports, and installing drivers if necessary. Configuration of the RDK platform is essential to recognize the device, with adjustments made if needed. Thorough testing is crucial to guarantee proper functionality. Specific remote control units like T4H Lima and UEI Tatlow, which align with RDK's Voice RCU Spec, may differ in keymap configurations, typically implemented at the OEM/SoC layer. The RDK platform offers support for key mapping through IRMgr and Bluetooth HID, although custom implementations would be required if the RCUs deviate from the standard, necessitating integration support from the OEM/SOC.

For RCUs that align with the RDK spec and offer features such as voice and firmware upgrades, the RDK platform can handle these functionalities seamlessly. If RCUs are Bluetooth-based and follow the BT HID standard, additional stack-side changes may not be necessary. However, if specific features like voice control and firmware upgrades are required and not covered by standard Bluetooth profiles, RCU-specific implementations may be needed, with integration support provided by the OEM/SOC. The RDK Control Manager plugin is available to facilitate these integrations, ensuring compatibility and smooth operation of the peripheral devices with the RDK box.

Additionally, for detailed information on how to integrate a new remote control device and how to integrate a pre-certified remote into your box, you can refer to the following link: Remote Controls Architecture.

User Interface

RDK supports the usage of different User Interfaces in the RDK devices. Operators can either choose from among the open-source User Interfaces that are already available with RDK or develop and use their own User Interface.

The RDK Accelerator Home UI version 3 is the latest version of the RDK reference UI, based on the Lightning framework, which provides a full-featured UI with a modern minimalistic design using a dark theme. This single UI currently supports IP-STB, Hybrid-STB, and TV profile RDK stacks. The UI uses Lightning SDK Plugins such as Language, Router, and Storage and supports Premium streaming applications such as Amazon, YouTube, and Xumo along with a selection of Lightning apps from the Metrological App Store. It also includes a wide section of settings that allow a user to take full advantage of the device features such as Audio, Video, Network, Language, and more.

 For further details, please refer to RDK Accelerator Home User Interface documentation.

Image Upgrade

XCONF is a management service that facilitates efficient image upgrades for set-top-boxes (STBs). It enables centralized control, monitoring, and firmware updates for optimal performance, security, and scalability. XCONF allows to define instructions for STBs and works alongside Device Configuration Manager (DCM) to remotely manage devices. The core component, the Xconf data service, communicates with STBs and a Cassandra database to store firmware configurations and other data. By leveraging XCONF, STB image upgrades can be efficiently managed and customized. For more details refer to Xconf .

Certification

Under certification, there are two sub-sections:

• RDK Certification 

• Firebolt Certification

RDK Certification: 

RDK certification program facilitates users to get their Video Accelerator product certified as an RDK compliance device.

RDKM provides the RDK Certification suite to verify the compliance of the RDK Video Accelerator device. The certification program includes testing that validates the RDK stack on the user platform with a defined test suite called as RDK Certification Test Suite. It is mandatory to go through this program in order to brand the user's platform as an RDK-compliant product.

Firebolt Certification:

Firebolt Certification entails confirming that a specific implementation of Firebolt on a particular device satisfies all the essential requirements outlined in the Firebolt specification. This certification process employs a comprehensive set of automated tests, test harnesses, and applications known as the Firebolt Certification Suite. The Firebolt OpenRPC specification serves as the authoritative reference for Firebolt Certification. Every software release intended for running Firebolt applications on any device must undergo this certification process.

Refer Firebolt Certification Suite document which provides a comprehensive guide for setting up the Firebolt Certification Suite (FCS), designed to enable both internal and external parties to verify that their applications comply with Firebolt standards.