Introduction to the Data Model Architecture for Embedded Systems

John Taylor - Watch Now - EOC 2024 - Duration: 33:19

John Taylor

Abstract Test Your Knowledge Questions & Comments (3)

The Data Model architecture is used to design highly decoupled code. It allows for the exchange of data between modules with neither modules having dependencies on each other.

Outline of topics:

Introduction
Why do I care about dependencies?
The Basics
Simplified Testing
Example
Change Notifications
Additional Features
Does and Don'ts
Data Model vs. Global Variables

1 / 4

Please log in or create an account to test your knowledge and see the answers.

According to John Taylor, what is the core rule of the Data Model architecture for designing modules in an embedded system?

A Modules should depend on data (model points) rather than depending on other modules.

B Modules should depend directly on low-level drivers to ensure performance.

C Modules should share global variables to minimize indirection.

D Modules should be tightly coupled so that changes propagate automatically.

E Modules should always implement behavior inside model points so data carries its own logic.

What primary problem does John Taylor say the Data Model architecture is intended to address?

A Managing dependencies to build change-tolerant software.

B Maximizing runtime performance of device drivers.

C Reducing code size to fit smaller microcontrollers.

D Eliminating the need for unit tests by centralizing logic.

E Forcing all modules to run on the same scheduling thread for determinism.

Which statement best describes the guarantees around change notifications (callbacks) for model points in the framework?

A You are guaranteed to receive a callback, but you may not receive every intermediate change — at minimum you'll get the final change when things calm down.

B You are guaranteed to receive every single change callback in the exact order they happened, with no misses.

C You will receive callbacks only if you poll the model point; subscriptions do not trigger them automatically.

D Change notifications always include a full history of intermediate values so subscribers can replay changes.

E Callbacks are only delivered synchronously and will block the model point from further updates.

What does John Taylor recommend when implementing generic drivers or middleware that need model data?

A Pass a reference or pointer to the model point instance into the module rather than hard-coding or creating the model point inside the module.

B Have the driver create and own its required model points internally so it controls their lifecycle.

C Use globally-named model points in the driver so all applications can find them by name without wiring.

D Require modules to discover model points dynamically at runtime instead of receiving references.

E Embed behavioral logic directly inside model points so drivers can call a single interface.

M↓ MARKDOWN HELP

italics	surround text with asterisks
bold	surround text with two asterisks
hyperlink	[hyperlink](https://example.com) or just a bare URL
code	surround text with `backticks`
~~strikethrough~~	surround text with ~~two tilde characters~~
quote	prefix with >

Upvotes Newest Oldest

Irshadjs

Score: 0 | 2 years ago | no reply

Thank you, John.

Scott.Becker

Score: 0 | 2 years ago | no reply

Thanks for the great presentation. This is a very interesting architecture and I'm going to investigate it further for use in future proejcts.

Nathan3

Score: 1 | 2 years ago | no reply

Thanks for the presentation. The valid / invalid attribute of a model point looks like it could be implemented using std::optional in C++ that Ben Saks presented in its workshop.

Login

Topic(s) Covered

About John Taylor