Open source, reusable software stack enables real-time processing and CbM algorithm development

Open-Source, Reusable Software Stack Enables Real-Time Processing and

Algorithm Development for CbM

Open source, reusable software stack enables real-time processing and CbM algorithm development

Introduction to CN0549 Condition Monitoring Platform

In this article, we will focus on the software ecosystem, data analysis tools, and software integrations available for the different components of the CN0549 and how engineers and data experts can use them for application development. This is the second in a two-part series on using the CN0549 development platform for condition monitoring (CbM) and predictive maintenance (PdM) applications. The new platform is designed to accelerate the development of custom CbM solutions from prototyping to production. The first part focused on MEMS vibration technology and capturing high-quality vibration data for CbM applications.

The entire process from concept to production and how to speed up the process!

When building condition monitoring solutions, they must include sensors, local processing, connectivity, and some form of software or hardware to enable them to function properly. The CN0549 offers customizable hardware and software options, allowing engineers and software developers to use common tools and infrastructure and make trade-offs based on the application design to address all of these challenges. For example, if you want to choose a specific microcontroller or FPGA for processing, want to use Python for coding, or have a favorite sensor that you want to reuse. This makes the CN0549 a powerful platform for those looking to build optimized CbM solutions to customize processing, power, performance, software, and data analytics to their needs.

Embedded system development process

Let's look at the entire development process of an embedded system from concept generation to production. Figure 1 outlines this abstract process.

In the design flow shown in Figure 1, step 1 is the “data study” phase. In this phase, users translate their requirements into different hardware and software requirements for the application. From a hardware perspective, parameters such as shock resistance, analog signal bandwidth, or measurement range may be involved. When considering software requirements, the number of samples, sampling rate, spectrum, oversampling, and digital filtering are all important parameters for CbM applications. The platform is very practical and flexible, allowing researchers to use different sensor combinations and adjust data acquisition parameters to meet their application needs.

After the "data research" stage comes the "algorithm development" stage, which is mainly to verify the application or use of the system. This usually requires developing models or designing algorithms in high-level tools and eventually porting them to embedded systems. However, before optimizing the design, it must be verified using real data and hardware loops, which is where CN0549 excels, because it can not only be directly integrated with popular high-level analysis tools, but also supports hardware loop verification.

Once the design is verified, work begins on optimizing and embedding the required software components. During the "embedded design refinement" phase, some algorithms or software layers may need to be re-implemented for use in an FPGA or resource-limited microcontroller. Care must be taken to continually verify the design as it is ported to a prototype or to hardware that will go into production for final verification.

Figure 1. Embedded system development process

Finally, the "production" phase is reached, which may bear little resemblance to the original development environment in which the design began, but still must meet the same requirements. Because the final system may be very different from the original research system, it may be impossible or difficult to run the same code or tests. This can lead to production test problems and equipment failures, which will most likely require additional time and money to remedy.

Reduce risk by maximizing reuse

One of the easiest ways to reduce risk during the design process is to reuse as many hardware and software components as possible at each stage, and the CN0549 provides developers with many out-of-the-box resources that can be used directly at each stage of the development process. The CN0549 solution provides schematics and board layout files, an open source software stack for optimized and full-featured environments, and integration options available for higher-level tools such as MATLAB® and Python. End users can use ADI's proven components and choose the components they want to maintain or change during the research phase to the production phase. This allows end users to focus on software development and system integration without having to draw schematics of ADI components or perform basic software development. Using hardware modules and reusing software layers, such as device drivers, HDL, or application firmware provided by ADI, can reduce the development time required to build a system and greatly accelerate time to market.

Software Development Process and Procedure

During development, CN0549 provides engineers with multiple options, allowing them to use common languages, including C or C++, while using familiar data analysis tools, such as MATLAB or Python. This is achieved primarily by leveraging and building on open source standards and existing solutions that support multiple embedded platforms from different manufacturers.

CN0549 System Stack

The system stack shown in Figure 2 provides an overview of the different components that make up the CN0549 system. The dark blue boxes in the upper left corner represent the sensors and data acquisition (DAQ) boards, and the light blue and purple boxes represent the FPGA partitions for data processing. The platform directly supports Intel DE10-Nano and Xilinx® CoraZ7-07s, covering two major FPGA vendors. The green boxes represent the connection to the host PC. This provides direct data access from the hardware to advanced data analysis tools for algorithm development.

All hardware description language (HDL) code is open source, allowing developers to modify it to insert digital signal processing (DSP) into the data flow of the programmable logic (PL), as shown in Figure 2. This can be anything from filters to state machines or even machine learning, depending on your system partitioning, and this step can also be done in user space or at the application level. Because the code is publicly available, it can be ported to other FPGAs from different manufacturers, or different processor families, depending on the needs of the end application.

Figure 2. System stack of the CN0549 platform

There are two software options available inside Arm® processors. Which one to use depends on the specific use case, but most developers will probably use:

u Linux®: Kernel drivers for DAQ shields built on the Industrial Input-Output (IIO) framework in the kernel. It is combined with a full embedded Linux distribution called Kuiper Linux that runs in the Arm kernel user space and is based on the Raspberry Pi OS.

No- OS : Bare metal project, using the same drivers as in the Linux kernel, can be used in Xilinx or Intel SDK. It can also be implemented in a real-time operating system (RTOS) environment as an alternative.

It is recommended that developers start learning and developing with Linux because Linux provides the most tools. Linux also provides a large number of development packages and drivers, which constitute the required development environment. When the system design is stable and ready for optimization, it is common to move to an OS-less environment, providing only the necessary software. However, this depends mainly on the application, and many manufacturers will deliver a complete Linux system to maintain the flexibility they want to provide.

As with the HDL used for programmable logic, the entire kernel source code, Kuiper Linux images, and the No-OS project are all fully open source, allowing end users to change components as they wish. If necessary, these code bases can also be ported to different processor systems or different runtime environments.

The last component shown in Figure 2 is the connection to the host PC, as shown in the green box. When running this system, the device can be configured and the data stream can be backed up to the host system for analysis. Developers will use standard tools such as MATLAB or TensorFlow to create algorithms on the host. Ultimately, these algorithms will be transferred to the embedded target, allowing them to use local processing power to speed up algorithm development iterations.

Accessing CbM Data – Getting Started

Using Arm processors and PLs typically occurs later in the design process, when the system is optimized for deployment. Therefore, a common initial entry point for developers is to connect remotely from a workstation to the embedded system. When running Linux on an embedded system, running code remotely or locally on a workstation is a relatively transparent process because of the way the infrastructure is designed. This is mainly due to an open source library called libIIO. libIIO is an interface library that allows for a simple, consistent access model for different device drivers to be built within the kernel's Linux IIO framework. This library is at the heart of the ability to use the CbM platform flexibly and provides data streaming and device control capabilities.

libIIO itself is mainly divided into two parts :

u libIIO library, which is a C library for accessing different IIO driver properties or functions. This includes streaming data to or from devices such as ADCs, DACs, and sensors.