- What the Nine Domains Actually Are
- Exam Format and Who Can Sit It
- Domains 1-2: LabVIEW Real-Time and NI Scan Engine
- Domain 3: LabVIEW FPGA
- Domains 4-5: Data Communication and Hardware Synchronization
- Domain 6: Reliability
- Domains 7-9: Test, Deployment and Integration
- Sequencing the Domains in Your Prep
- Where CLED-1 Ends and CLED-2 Begins
- Frequently Asked Questions
- CLED-1 covers nine topics, but NI publishes no percentage weights, so budget study time by your own experience gaps.
- The written exam has 30 multiple-choice questions in one hour, with a 70% passing mark.
- Passing CLED-1 alone does not confer certification; the five-hour CLED-2 practical on Single-Board RIO hardware is separate.
- Entry requires active Certified LabVIEW Developer (CLD) or Certified LabVIEW Architect (CLA) status.
What the Nine Domains Actually Are
The Certified LabVIEW Embedded Systems Developer credential from National Instruments (NI) tests whether you can build, deploy, and troubleshoot deterministic control and monitoring applications on CompactRIO, Single-Board RIO, and R Series hardware. The written portion, CLED-1, is organized into nine topics taken directly from NI's official preparation guide. This article walks through each one and explains what the subtopics demand in practice.
One caveat shapes everything that follows: the nine topics are unweighted. NI does not publish a percentage breakdown, so you cannot reason that one topic is "worth 25% of the exam." Any weighting you see in a practice resource, including the practice question allocations on our own CLED practice test site, is an editorial judgment about emphasis, not an official blueprint. Treat the list below as nine areas of roughly unknown size and let your own weak spots decide where the hours go.
| # | Domain | Core Technology Focus |
|---|---|---|
| 1 | LabVIEW Real-Time | Priorities, execution systems, multicore, error handling |
| 2 | NI Scan Engine | Scan modes, timing, fault handling |
| 3 | LabVIEW FPGA | Arbitration, DMA FIFOs, fixed-point, SCTL, compile reports |
| 4 | Data Communication | Tags, network streams, messaging, TCP/UDP |
| 5 | Hardware Synchronization | Backplane sync, clocks, IEEE 1588, NI Time Sync |
| 6 | Reliability | Failure modes, watchdogs, redundancy, memory |
| 7 | Test, benchmark and debug applications | Execution Trace Toolkit, benchmarking, headless debug |
| 8 | Deployment | System images, EXE startup, updates, touch panels |
| 9 | Integration with other LabVIEW Modules | DSC Module alarms, events, and trends |
Exam Format and Who Can Sit It
According to NI's CLED guide, CLED-1 consists of 30 multiple-choice questions to be completed in one hour, with 70% required to pass. It is proctored. Because the questions are scenario-driven, expect to read short descriptions of a system and choose the correct architecture, setting, or diagnosis rather than recall isolated definitions.
Eligibility is gated. You need active CLD or CLA status before attempting Part 1, and you must pass Part 1 before attempting Part 2. NI recommends 18-24 months developing medium-to-large LabVIEW control and monitoring applications using CompactRIO, Single-Board RIO, or R Series hardware, or mastery of the relevant embedded-control training. For a fuller breakdown of the prerequisites, see our guide to CLED requirements and how to qualify, and for the score threshold specifically, read CLED passing score: exactly what you need to pass.
Domains 1-2: LabVIEW Real-Time and NI Scan Engine
Domain 1: LabVIEW Real-Time
LabVIEW Real-Time
This is the conceptual foundation of the exam. Candidates must reason about how the Real-Time OS schedules work and how poor design causes jitter or missed deadlines.
- Thread priorities, and how execution systems relate to threads and priority
- Priority inversion, shared resources, and starvation
- VI priority versus Timed Loop priority, and OS thread priority
- Analyzing application requirements and mapping them to priorities
- Error handling and logging
- Multi-core programming
The trap here is treating priorities as a simple "higher number wins" rule. Exam scenarios tend to describe a deterministic loop that occasionally slips and ask you to identify the cause: a shared resource held by a lower-priority task, a non-deterministic call inside a time-critical loop, or an execution system assignment that puts work on the wrong thread. If you cannot explain priority inversion in your own words and name a fix, drill that before anything else.
Domain 2: NI Scan Engine
NI Scan Engine
The Scan Engine abstracts I/O into a periodic scan of channels. The exam tests when to use it and when not to.
- Applying and selecting between NI Scan Engine, Hybrid Mode, and LabVIEW FPGA Mode
- Scan Engine timing considerations
- Handling Scan Engine faults
Know the trade-off: Scan Engine gives you fast development and tag-based access with modest timing guarantees, while FPGA Mode gives you custom, high-speed logic at the cost of more development effort. Hybrid Mode lets you mix both on one chassis. Questions typically hand you a requirement (loop rate, custom triggering, number of channels) and ask which mode fits.
Domain 3: LabVIEW FPGA
FPGA programming is where many Real-Time developers feel least comfortable, and the subtopic list is specific enough that vague familiarity will not carry you.
LabVIEW FPGA
Expect questions about both correctness and resource efficiency.
- Emulation mode and its limitations
- Arbitration for shared resources
- Buffering techniques for DMA FIFOs
- Fixed-point data types for FPGA operations
- Enable chain behavior
- Optimizing for space/size and for performance (throughput and Single-Cycle Timed Loops)
- Reading the compile report
Two skills deserve extra attention. First, DMA FIFO sizing and buffering: understand why FIFOs overflow, how host-side read rates interact with FPGA write rates, and what buffering strategies prevent data loss. Second, compile report interpretation: be able to look at resource utilization and timing figures and judge whether a design will fit and meet timing. The same skill reappears in Domain 7, so it pays off twice.
Domains 4-5: Data Communication and Hardware Synchronization
Domain 4: Data Communication
Data Communication
Choosing the right transport for the right data is the central skill.
- Commands, tags, and streaming as distinct data patterns
- Best practices for tags, network streams, command/message schemes, and FPGA interprocess communication
- TCP and UDP trade-offs
- UDP multicast and broadcast
- Client-server architecture
A useful mental model: commands need reliable, acknowledged delivery; tags suit continuously updated current values where only the latest matters; streaming moves high-volume data where throughput and buffering dominate. Exam scenarios often describe a mismatch (for example, using a lossy protocol for a command that must not be dropped) and ask for the correction.
Domain 5: Hardware Synchronization
Hardware Synchronization
Distributed and multi-module systems need a shared sense of time.
- FPGA synchronization via a shared backplane bus
- Clock synchronization for distributed systems
- Synchronization bottlenecks
- IEEE 1588, NI Time Sync, and SMTP protocols
This is one of the shorter topic lists, but it is conceptually dense. Be able to explain why distributed measurements need a common time reference, what limits synchronization accuracy, and how the protocols named above fit in.
Domain 6: Reliability
Reliability has the longest subtopic list of the nine, running from failure modes through memory allocation behavior. It reflects the reality that embedded systems run unattended and must fail safely.
Reliability: Failure and Recovery
Design for what happens when things go wrong.
- Failure modes and failure states
- Redundancy and alarming
- Error logging and system health monitoring and maintenance
- LabVIEW Real-Time watchdog and the LabVIEW FPGA watchdog (Fail Safe Control Architecture)
- Acknowledgement-based reliable communication
Reliability: Memory on Real-Time Targets
Memory behavior is a distinctive embedded concern that desktop LabVIEW developers rarely face.
- Types of memory allocation, and which components allocate memory
- Non-application components (DMA, drivers, TCP) that affect memory
- Memory fragmentation and its impact on RT targets
- Buffer allocation and its effect on memory
- Behavior of LabVIEW Real-Time when the system runs out of memory
- Coding practices for working with fixed-size data
Because this domain is so broad, split it into two passes: first the watchdog, redundancy, and failure-state material, then the memory material. Candidates who rely on desktop instincts tend to underestimate how destructive repeated dynamic allocation is on a long-running RT target, so fixed-size data strategies are worth rehearsing.
Domains 7-9: Test, Deployment and Integration
Domain 7: Test, benchmark and debug applications
Test, benchmark and debug applications
Measure, do not guess.
- Testing system functional requirements
- Benchmarking uptime, throughput, and data rates
- Using the LabVIEW Real-Time Execution Trace Toolkit for thread and VI execution, memory allocation, and resource contention
- Benchmarking memory usage, CPU usage, execution time, throughput, latency, jitter, and FPGA usage
- Interpreting a compile report to estimate whether an FPGA program will fit
- Preparing a system for benchmarking by removing unused software components, disabling debugging, and building an executable
- Debugging and extracting benchmark information from a headless system with console, syslog, and other tools
The preparation step is easy to overlook: benchmarks taken with debugging enabled and extra software installed are not representative. Expect at least one question on how to set up a valid measurement.
Domain 8: Deployment
Deployment
Getting a working application onto many targets, and keeping it updated.
- Creating a system image for replication
- Using system configuration tools for deployment
- Building an EXE and setting it as startup
- Deploying NI Scan Engine and shared variable settings
- Deploying software and runtime updates, including updates applied on reboot
- Deploying and replicating touch panels
Domain 9: Integration with other LabVIEW Modules
Integration with other LabVIEW Modules
The published detail centers on logging and displaying alarm, event, and historical trend data with the LabVIEW Datalogging and Supervisory Control (DSC) Module. It is the narrowest topic on the list, so it rewards focused, efficient review rather than a large time investment.
Sequencing the Domains in Your Prep
Since NI publishes no weights, order your study by dependency rather than by guesswork. Real-Time concepts underpin Scan Engine, Reliability, and Test, so they come first. FPGA and Data Communication are independent enough to study in parallel. The following sample timeline is one reasonable arrangement; adjust it to your background.
Real-Time and Scan Engine
- Priorities, execution systems, priority inversion
- Choosing between Scan Engine, Hybrid, and FPGA modes
LabVIEW FPGA
- DMA FIFO buffering, arbitration, fixed-point types
- Compile report reading and SCTL optimization
Communication and Synchronization
- Matching tags, streams, and messages to data patterns
- Time sync protocols and distributed clocks
Reliability, Test, Deployment, DSC
- Watchdogs, memory behavior, and failure states
- Execution Trace Toolkit, system images, DSC alarming
For a broader plan covering how to pace the whole effort, see our CLED study guide, and keep the CLED cheat sheet handy for last-day review. Official preparation material includes the LabVIEW for CompactRIO Developer's Guide and the CLED sample materials from NI. Once you have covered the domains, test yourself with timed questions on our practice test platform to see which of the nine areas still cost you points.
Where CLED-1 Ends and CLED-2 Begins
A frequent point of confusion is how the nine domains relate to the hands-on assessment. They do not map one-to-one. The nine topics describe the written CLED-1 exam. CLED-2 is a separate five-hour, application-development practical built around Single-Board RIO hardware, administered onsite at NI facilities or an arranged location, with a 70% pass mark of its own. Its grading rubric is not a written-topic weighting scheme, and it cannot be treated as a longer multiple-choice test or as something a question bank alone prepares you for.
Key Takeaway
Passing CLED-1 alone does not make you a Certified LabVIEW Embedded Systems Developer. Certification requires passing both parts in order, and it remains valid for five years, with renewal through the CLED exam or approved recertification-by-points activities. Use the nine domains to clear the written gate, then build real Single-Board RIO project time for the practical.
If you are weighing whether the full two-part path is worth the effort, our analyses of how hard the CLED exam is and whether the certification is worth it can help you decide, and CLED certification cost covers the budgeting side.
Frequently Asked Questions
Nine: LabVIEW Real-Time, NI Scan Engine, LabVIEW FPGA, Data Communication, Hardware Synchronization, Reliability, Test, benchmark and debug applications, Deployment, and Integration with other LabVIEW Modules. They come from NI's official preparation guide for the multiple-choice exam.
NI publishes no percentage weights for the topics, so no official weighting exists. Any breakdown you see elsewhere is an editorial estimate. Plan your study around your own weaker areas instead.
According to NI's CLED guide, CLED-1 has 30 multiple-choice questions in one hour, with 70% required to pass. It is proctored, and you must hold active CLD or CLA status to attempt it.
No. CLED-1 is a prerequisite. You must also pass the separate five-hour CLED-2 practical, which involves application development using Single-Board RIO hardware, before the credential is awarded.
Reliability. Its published detail spans failure modes, redundancy, watchdogs, alarming, and a long run of memory-allocation topics specific to LabVIEW Real-Time targets, so it deserves a dedicated block of study time.