Whitepaper: The Brick Model

How the RDK stack is built, versioned, tested and released.

This is the idea behind the RDK-E model of component release: every component is released on its own, with a version number, and a product is assembled only from released components.

A picture guide for product teams. Component names are real HAL modules; version numbers are examples.

Why this matters

• One middleware for every product. The same middleware and app layers run on every box and TV; only the vendor layer underneath differs. One thing to test, support and upgrade.
• Something working always ships. Every brick and every wall is tested and numbered before anyone may use it, and the last working version is always still there.
• You choose which version you take. A product can take a newer middleware and keep its vendor layer, or the other way round.
• A date never forces a release. Things go out when they pass, not because it is Monday or month end.

The rest of this guide shows how each of those is made true, one picture at a time.

1. The product: bricks, walls, one stack

Every software component is a brick with a name and a version number. Bricks are built into three walls: vendor, middleware and application. Each wall has a version number of its own: "middleware wall v7" always means the same exact set of bricks. The walls stand on the kernel, the base everything rests on.

The gold section is supplied by the vendor but used by every wall (the graphics and Bluetooth libraries, for example). It only changes at a new generation, RDK9 to RDK10, and when it does, everything above it is rebuilt.

Only the vendor wall differs between products. Middleware and app are the same release on all of them, down to the last byte.

2. Making bricks

Teams work on their own clock and can be years ahead of what products ship. Their work in progress ("develop") is never used in a product. A brick exists only when the team stamps a version on it, tests it on its own, and puts it in the store. One version may bundle many changes.

Some bricks only work at matching versions. Those are released as a group with one version of its own, and are always picked together.

A brick is made once, when its version is stamped. After that it is only ever copied. The brick that ships is the very same brick that was tested, which is what makes the test result worth anything.

3. Building walls

The Layer Release Manager (an engineering team) builds a wall from a pick list: the exact version of every brick and group that goes in. It takes finished bricks from the store, never makes new ones, and tests the wall as a whole and together with the wall below it. A wall that passes goes on the shelf with its own version number.

If a brick fails, its team fixes it and stamps a new version, or the pick list goes back to the last version that worked. Either way the wall is tested again. The loop has no clock.

4. Choosing walls for a product, and getting it to customers

The Release Manager (a product role) builds a product from whole walls on the shelf, choosing the previous, current or next version of each. It never touches bricks and can never choose a wall that has not passed.

Before a product takes a new wall, the same tests are run against the old wall and the new one. The difference between the two result sheets is what the upgrade changes. Anything that used to work and now doesn't is judged on its risk and signed off, or the product stays where it is.

A new wall reaches customers in stages: first on real hardware in the lab, then a small group of trial homes, then everyone. Every new wall gets at least one full pass through those stages. A failure at any stage goes back to the owning team, and the previous version stays available the whole time.

5. Testing: what each gate proves

A test is a plate that clips on to the stack, proves one thing, and comes off before shipping. A feature is tested on its own, then inside the middleware, then the way a customer would use it. Every vendor's wall, whichever chip is underneath, passes the same test, which is what lets one middleware sit on all of them.

Gate	Who	If it fails
Brick gate	The brick's engineering team	No version stamped; it never reaches the store
Wall gate	Layer Release Manager (engineering team)	Wall not released; the brick is fixed or backed out, and the wall tested again
Product gate	Release Manager (product)	New wall rejected; the previous wall is used

There is always a known-good fallback, so a failure never means choosing between broken and nothing, only which working version to ship.

6. Swapping one feature

The goal is to replace one feature, say HDMI-CEC, without a whole new release: its bricks across the walls swapped as one column. That is only safe when the feature has its own test that runs from the top down through every brick it owns. Much of today's stack is older than this model, so features are being turned into swappable columns one at a time.

What this means for product

You ask	The model answers
Is it ready?	Only bricks that passed their test have a version and reach the store.
Will it work together?	Every wall passes its test before release; the product passes its test before it ships.
One build for many devices?	Yes. One middleware wall and one app wall, reused on every product. Only the vendor wall differs.
Must we take the latest?	No. You can choose the previous, current or next version of each wall.
What if the latest fails?	Fall back to the last working version. Something working always ships.
Can we release on a fixed date?	A date is a target. The release goes when it passes, not because the date arrived.
How fast can a new wall reach customers?	Never faster than one full pass: lab, then trial homes, then everyone. A failure adds a fix-and-retest loop.
What will an upgrade change?	The same tests are run on old and new; the difference is the answer.
Does assembly rebuild anything?	No. The brick that ships is the brick that was tested.
Can we replace one feature only?	Where that feature has its own top-down test, yes.
When is a big rebuild needed?	When the gold section changes, which only happens at a new generation (RDK9 to RDK10).

Appendix: the words

Term	Plain meaning
Brick	A software component with a name and a version
Group	Bricks that must be used at matching versions, released together with one version
Wall	A layer: vendor, middleware or application, with its own version number
Gold section (VSI)	Vendor-supplied libraries used by every wall; fixed for a whole generation. Vendor System Interface, like Android's VNDK
HAL	The join between the middleware wall and the vendor wall; a vendor can add to it without breaking the wall above
Store	Where finished, versioned bricks live
Shelf	Where tested, versioned walls live
Pick list	The exact version of every brick (or wall) that goes into a build
Layer Release Manager (LRM)	Engineering team that builds and tests walls from a pick list
Release Manager (RM)	Product role that chooses which version of each wall goes into a product
Comparison test	The same tests run on the old and new release; the difference is what the upgrade changes
Column (vertical)	One feature's bricks across the walls, swapped as a unit, with its own top-down test
Test suites	MTS: one feature on its own. TTS (Thunder, the middleware framework): inside the middleware. FTS (Firebolt, the app platform): as the customer sees it. VTS: the vendor wall, same test on every chip
Gate	A test that must pass before anything is versioned, released or used