Manage Embedded Software through Software Architecture and Design Rules for a No-Line PCB Design

Recently, Amazon opened its first grocery market where one of its main points was its refusal of lines. Of course, its first-day publicity was a line of people outside waiting to try it out. I’m sure that as the newness diminishes it will be able to fulfill its promise of no lines; however, for now, I am mostly hoping that the store still had some rules in place in-case there was a line. After all, if one of your basic premises is to avoid lines, then I imagine it could be quite easy to descend into a lawless, food-grabbing domain of swinging baskets and carts ramming into each other.

Much of the more basic etiquette of grocery markets is implicit these days: enter and exit through appropriate doors, avoid leaving your cart in the middle of aisles, don’t attempt carrying more than an armful, etc. There’s a sequence to the rules you follow upon arriving at a grocery market, and so long as everyone pays attention to these rules then the order is maintained.

A similar sequence of rules and rule-following can apply to developing embedded software. A fundamental path to success includes defining performance requirements and establishing stable design rules. It will ensure that, even if everything goes wrong, you have a steady backbone to your design which you can rely on to catch and potential errors and keep your designing moving forward.

Embedded Design Software Begins with Design Rules for Performance Requirements

Refrigerators, complex avionics systems, robotic vacuum cleaners, and other devices rely on embedded software for managing multiple tasks. A smart refrigerator might interact with the IoT to connect with its owner’s smartphone and leave a message about milk beginning to sour. The embedded software within the refrigerator uses DSPs to control tasks, works within microcomputers and microcontrollers for peripheral tasks, and communicates with sensors and other devices.

Embedded software applications vary from controlling basic operations to running all components of complex avionics systems. Application design begins with an analysis that produces a detailed list of performance requirements for the project.

Performance requirements for embedded software influence the selection of a computing platform, the I/O signals, and the software architecture. The architecture defines the organization of the system, covers the relationships between the environment and its components, and governs design.

Constraints and Risks Challenge Embedded Software Development

The operation of an embedded system and its software relies on relationships between components and between the system and its environment. None of this occurs without limitations. Constraints set the boundaries for system operation. Many of the same factors—such as safety, cost, interfaces, and compatibility—that serve as performance requirements also define constraints.

Real-time interactions between embedded processors, sensors, and actuators set boundaries for development. While processors have memory, response time, and speed constraints, the software architecture may become vulnerable with the addition of more complex tasks and miss deadlines.

As a result, some constraints evolve into risks. Changing requirements for hardware and software platforms introduce some uncertainty in embedded software development. Hardware manufacturer control over language, tools, and the database used by the development team may hinder flexibility. Reliability—whether for consumer devices or for industrial controls—also exists as a risk.

Design Rules Keep Your PCB Design Safe From Failure

Design rules are stable design decisions and serve to strengthen your embedded software development. The design decisions decouple the embedded system architecture into modules through stable interfaces such as abstract data types. Strong design rules occur as key header files, globally shared data structures, and other design patterns and interfaces.

Well-thought design rules also cover the logic that governs interaction between people and their devices (UI), the domain logic, the data-handling logic, and define relationships between subsystems. Design rules and design decisions frame the hierarchical modular structure of an embedded system. Upper layers of the hierarchy contain design rules while lower layers contain design decisions that depend on upper layer decisions.

Based on performance requirements and design standards, the rules determine the level of interaction between the subsystems. When miscommunication threatens how teams manage a software project, risks emerge. Teams lose the ability to produce the high-quality code needed for managing complex systems and applications. Design rules establish a language for the project and add consistency to team communication.

With the right PCB design software, you’ll be able to manage your embedded software through specific and potent design rule constraints. Thankfully, there are strong options out there for you to choose from like Altium ^®’s CircuitStudio, with a large of constraints and smart design software checking for errors throughout your process.

If you have more questions about designing with embedded software, consider talking to the experts at Altium today.