EMBEDDED COMPUTING SYSTEMS FOR OEMS AND ISVS

What is Embedded Computing?

Embedded computing systems are incredibly prevalent and essential to the functioning of an enormous variety of devices, from consumer- to medical-grade. Ensuring these systems are always up and running is essential to the functioning of many life science, aerospace, and medical systems.

Embedded computing systems are task-specific, despite being part of a larger system. These systems are made up of hardware and software. Some are programmable and others aren’t. All embedded computing systems need to be both efficient and reliable. This resource will explore some of the ways OEMs and ISVs can get the most out of their embedded computing systems.

How Can OEMs Get Started with Preventative Maintenance?

Developing compute systems for longevity is a powerful tenet of embedded design and manufacturing. Long-term deployments in mission-critical settings are common and are a driving force in how computing systems are designed, realized, and managed. Keeping systems in the field generating revenue is a crucial part of this effort, requiring planning and management that include smart strategies for extended support and service.

Recognize “Service” as an Opportunity

Taking ownership of the repair process means taking it personally, with a responsibility borne from being the manufacturer of the product itself. A service center within an original design manufacturer (ODM) or system integrator is more than just a repair center, and extended support is more than lifecycle management. Original equipment manufacturers (OEMs) can seize the opportunity to learn from the “economies of skill” as they partner with an ODM service center.

For example, how an ODM collaborates with a medical device manufacturer to identify common failure modes is critical. Failures may be unrelated to components and instead might result from the way a particular end user interfaces with the system or from the environmental design of the deployment. ODMs bring experience to the table in solving these issues, with firsthand knowledge of system failures in common healthcare settings that can help OEMs prevent additional failures in similar settings. 

Define Your Extended Support Strategy 

A strategic support program takes a broad approach to system repair, recognizing that embedded systems are often just too critical —and too costly—to tolerate downtime. When repairs are required, they must occur rapidly and appear seamlessly to the customer. As a strategic partner to an OEM, an ODM focuses on continually adding value to an ongoing design and manufacturing relationship. It is this type of extended support partnership that is vital in keeping systems deployed and performing flawlessly. This ultimately reduces service and maintenance costs, which can greatly impact the overall downtime of the device or instrument.

For example, ODMs can routinely provide training to their customer’s repair depot and field staff, considering every opportunity to reduce impact of any kind to potential system failures. Remote diagnostics add exceptional value in this setting, creating a connection between the suspect device and the manufacturer’s server. Remote testing can quickly and conveniently uncover any existing hardware failure and include diagnostics to reveal any pending failure.

Uncover Root Causes to Prevent Reoccurring Performance Challenges

Repairing a system is important, but uncovering the root cause of an issue requires a much higher level of commitment from the service provider. Some solutions may not necessarily address the underlying issue as environmental failures may be difficult to replicate, causing the system to perform perfectly in a service center setting. This leaves room for future frustration. Yet, if the customer perceives an issue, there is an issue, and the system cannot be given a clean bill of health until the root cause of that issue is revealed.

“If the customer perceives an issue, there is an issue.” - Mark Villanova -- Service Manager, Dedicated Computing

By identifying and tracking the root causes of failure within systems that are delivered for service, the service center becomes a smart hub for service records and valuable data associated with the system. Problems are identified and logged, tapping into customer input whenever additional information is available to help refine the problem. Using a range of techniques, the root cause of any problem is determined and scored for routing depending on the type of problem itself. For instance, if the total cost of ownership (TCO) is the primary concern, scores may focus on cost. In contrast, if reliability is the leading factor, scores and the following actions will reflect that priority. This level of service goes beyond simply repairing a device and may include the comparison to manufacturing records, health and functional analysis, and nondestructive performance testing.

Importantly, all of this information is gathered and shared with the design team, educating designers about specific failures and their causes. Design teams then have real-world insight for smarter system layouts, and service teams know how to quickly address the most likely root causes when failures do occur.

The service center becomes a smart hub for service records and valuable data associated with the systems.

Stepping Up for Extended Support

With improved knowledge of what factors drive a potential failure, an OEM is better positioned to avoid future system failures. Proactive support programs can make a long-term difference, emphasizing the importance of a partnership between the customer and the system provider.

Successful partnerships between OEMs and ODMs require that service and support beyond the repair be considered integral to the design and manufacturing process. Strategic suppliers recognize this. Motivated by pride of ownership, they strive to build customer confidence in manufactured systems. With this approach, OEMs with mission-critical systems win big with reduced downtime and longer product lifecycles.

How to Make Smart Hardware Choices

Determining the right hardware platform for a sophisticated application isn’t always part of the discussion within the product development process. In many cases, a Bill of Materials (BOM) may have been established without insight into application specifics that are crucial to determining smart, cost-effective choices. The right methodologies for product consultation can make all the difference. Consultation drives the design process based on real-world goals for performance, system longevity, and Total Cost of Ownership (TCO).

This section contains six questions to help OEMs and ISVs select the right hardware design to best support their purpose-driven application and product.

1. What does my application actually require?

Custom versus off-the-shelf is typically the first consideration, as OEMs determine if their application requires a standard set of capabilities and compute power, or something beyond an off-the-shelf system. To capture the best of both worlds, Original Design Manufacturers (ODMs), like Dedicated Computing, provide extensive product catalogs, offering a well-defined starting point that can be fine-tuned for both performance and value. These designs tap into the ODM’s expertise, honed from developing specialized systems in highly competitive embedded markets. OEMs can win big by capitalizing on previously established catalogs of systems proven in the market for performance and longevity. Off-the-shelf is a legitimate option if buyers know the right questions to ask in advance. 

2. How do I align the hardware with my application? 

Early discussions in the system selection process address key areas of performance and potentially challenging preconceived expectations about specific components such as processors or GPUs. A deeper dive will determine how each component’s individual features and capabilities fit within the larger system. Four essential areas include CPU, memory, storage, and GPU—and should all be addressed for performance needs while considering the future scalability of the application.

3. How do I right-size my choice of processors?

Understanding clock speed requirements is a critical consideration in choosing a CPU, along with whether or not the application demands any special type of caching. High-end processors have a variety of built-in caching capabilities, with some offering 8MB and others closer to 20MB. The difference between these two cache points impacts cost, making it worthwhile to determine what the application really requires. A higher cache is ideal for applications that need to process large data sets very quickly. But is that what your application demands? Early discussions within the product development process will help OEMs avoid paying for 20MB of cache if it is not needed.

4. What are my expectations for memory needs as my application evolves over time? 

OEMs planning to ship a product for 10 years need a memory strategy that supports application growth over time, planning ahead to avoid unplanned hardware upgrades as a result. Applications may be written to require more memory, merely because of processor limitations at the time of their development. Yet data traffic has changed based on processor advancements, with additional lanes commonly available to access smaller pieces of memory faster. Often, applications simply require more memory to continue performing as steady improvements are made.

5. What are the pitfalls of defining a storage solution?

Storage requirements should be based on the size of the data, as well as how quickly the application needs to access it. Access falls into two categories—writing and saving data vs. reading and retrieving it. For example, within the life sciences industry, modern genomics applications are equally read-write intensive, writing large data sets for immediate reading. In contrast, an image-rendering application within the simulation industry might write just once to its large database, with ongoing reading activity being the heaviest load for the storage solution to manage. These considerations affect decisions about both the amount and type of storage that is optimized for the application.

Strategic suppliers can provide valuable help in making this determination, working with information provided by the OEM. Knowing the size of the overall data set as well as its anticipated growth over the lifetime of the application is crucial insight that drives the right choices here. Average file size matters as well—is the application transferring a fewer number of multi-petabyte files or thousands of much smaller files? And if the application writes and rewrites data, does the system account for write limitations common to SSDs? Many are designed with a read-only focus, with write capabilities defined by a limited lifetime that may impact the system lifecycle.

6. Do my support plans need to include frequent GPU upgrades?

As it relates to graphic-intense applications, choosing a GPU is largely influenced by how an OEM wants to manage its product. Cards that fall within the consumer or gamer category—for example, the NVIDIA GeForce®—change every 12 months or less. End-of-life (EOL) notices are not standard in this type of product environment, so OEMs must remain reactive to frequent change. If this is suited to the OEM’s operations and product lifecycle, they can win with some of the highest GPU performance at the lowest cost. However, if longevity and greater stability are required—often a factor in longer deployments of performance-critical systems—the OEM may be wiser to invest in a more costly three- to five-year GPU product. Costs per GPU are greater in this scenario, but actually may be more cost-effective once the GPU decision incorporates support and ongoing change needs as part of product development costs.

Strategy Must Play a Bigger Role in Design

Smarter hardware choices enable a cascade of value. With collaboration built into the design process, OEMs create a significant opportunity to improve the total cost of ownership (TCO). Performance is right-sized, and longevity is considered—for example, the OEM may have an opportunity to embrace something significantly less costly, even while protecting a long-term product roadmap. Support needs and ongoing changes are anticipated and planned, eliminating costly surprises and creating a clear understanding of price vs. performance.

By seeking only a system on which to deliver their application, ISVs and software-focused OEMs may discount the competitive value of right-sizing a system for specific performance. Yet the first communication between an OEM and their contract manufacturer is often a high-level look at an existing BOM. These preconceived notions about hardware can lead to potential issues above and beyond cost and performance, creating havoc in terms of longevity, parts availability, and ongoing maintenance. In reality, a strategic supplier can help combat these issues early in the selection process—recommending new products ready for smarter customization, or new technologies to consider based on a deeper knowledge of sub-technologies and their progress in the market.

Ultimately, with more collaborative practices and a broader view of their hardware requirements, hardware teams within the OEMs can bring to the table just the right amount of technology to meet application needs for the long term.

How Can a Security-First Mindset Drive Performance and Profit for OEMs?

In volatile embedded environments where threats are nonstop, original equipment manufacturers (OEMs) want to secure their devices and systems, but don’t necessarily understand how to maintain long-term protection.

This section outlines an original design manufacturer’s (ODM’s) perspective for design strategies and standards, providing OEMs a perspective for gaining a security-driven mindset.

By embracing security implementations and proactive risk management, OEMs can prevail in many ways—protecting systems, distinguishing their services, and driving new opportunities to create long-term profit centers from security services.

4 Quick Tips

• Built-in, rather than add-on security, starting with a baseline that protects performance, service, and maintenance

• Embrace consistent internal communication among design and development teams

• Tap into ODM partnership for security protocols as well as long-term security support

• Resist the urge to resist; being proactive can turn security maintenance into a profit center 

There’s Always a Hacker

Embedded systems are under siege—it’s a hacking war of software team versus software team, and the good versus bad. Simply put, OEMs must win more battles than they lose. Manufacturing partners can offer plenty of smart protocols to initially secure a system—whitelisting, freezing configurations, smart stack management, and many more. Yet, if an OEM lacks a security-forward strategy, these protocols will become obsolete as requirements and rules evolve over time.

Even more troubling is that cyber attacks can target any component within a system; devices don’t need to be connected to the Internet or part of a cloud solution to be vulnerable to security issues or threats. Ignoring or delaying security processes only adds to the jeopardy. Patching every quarter still trails the latest cyber threats, although it is an important part of a committed, proactive approach to long-term security management. 

Going Beyond Strategies and Standards

Customers of OEMs (e.g., a hospital), must support a plan to constantly update and maintain systems at a stable level, remaining compliant with security implementations and aware of evolving risks. Yet, part of the complexity is that every customer’s environment is different. For example, OEMs developing military training and simulation systems may need to deliver a range of training levels or handle secure data. Meeting Department of Defense security mandates may be required before a machine is authorized to perform in a specific building—secure machines must then be integrated into a secure infrastructure.

In a healthcare example, the IT organization within a hospital may need to shield a system even while sharing data with a range of other clinical stakeholders. Following FDA security guidance here is essential—OEMs must be prepared to ensure systems are maintained from the point hardware was manufactured through system deployment and the full lifecycle of the device in the field. Additionally, FDA guidance proposes increased cybersecurity measures associated with medical device servicing. These guiding principles demonstrate the growing expectation that OEMs will prioritize security from initial development through end user deployment.

In both industry examples, OEMs are tasked with developing device features that serve end user needs, while simultaneously instilling confidence that the system has its own protected surface. Remote access also plays an increasing role and must empower system managers across the spectrum of embedded applications to make changes and updates without compromising device or data security. Taken together, all these factors challenge OEMs who fail to tap into a security mindset to meet the demands of continuous hardware and software maintenance. 

Understanding Risks and Finding Opportunities

In contrast, when proactive security updates are part of the fabric of the organization itself, they become a feature—not a roadblock—that can connect with OS and hardware updates and be sold as a service. Keeping security update cycles in sync with application updates is a smart starting point, for example executing patches while updating to circumvent any vulnerabilities and implement performance improvements. A routine cadence of updates is not only a selling point and competitive distinction, but it is also a means of turning a cost center into a profit center.

More and more end-users are embracing OEM security services and capitalizing on security support that considers connectivity of end users, existing frequency of updates, confidential or otherwise sensitive data on the device, the cost of any potential losses, and much, much more. The OEMs building and managing unique devices play a key role determining the value of these issues—raising expectations for a security focus woven into every phase of development and manufacturing partnership. This is a salable shift in attitude and has created a powerful (and profitable) center for customer support.

4 Questions to Ask When Measuring Your Security Strategy

Developing a security mindset is a process and is based on an understanding of what is important to your business and your customers.

• What are your customers asking of you and how can your answer differentiate you from your competition?

• How can you remain compliant and secure while ensuring system performance? 

• What can your ODM partner do to help you consider vulnerabilities at every stage of design, development, and deployment? 

• Do you communicate well internally on security challenges and plans? Or, are they considered constant roadblocks that are pushed down the development list? 

Framing Your Security-First Mindset

Today, there is a whole new dimension of liabilities for OEMs to consider—and addressing them is not an entirely technical discussion. The concern will be different depending on each internal team’s priority. Administrators are often the first to acknowledge the need for security, if only as a path to make products more marketable. Engineers point out that resources are not available for constant updating and validation. The service team says there is not enough manpower to handle field updates efficiently. And the quality assurance staff questions how the OEM can document changes and ensure performance remains untouched. Progress, however, can be driven in large part by working with technology partners for security insight and support. ODMs often take on the role of facilitator, helping OEM teams communicate better internally and exploring options that help each of them maneuver to a strong security mindset.

Designing to standards and protocols is the easy part, with it being much more difficult to embrace security leadership as part of OEM operations. Proactive, broad thinking and partnerships are required—acknowledging that the security playground is large and constantly getting larger, with threat assessment that is both complex and greatly varied.