Embedded applications present a different set of challenges than regular systems that are not meant to run embedded in a target. A system that is not embedded has only functional requirements, i.e. what features the application is supposed to implement. Their embedded counterparts not only have to obviously implement the final system functional requirements, but also carry execution requirements; which is related to the interaction of the system with the chosen embedded target platform the application Software will run embedded in. Examples of execution requirements are the total amount of memory the application software should occupy, the amount of power the application will sink, how much jitter is acceptable for the control loop, how much storage space is required for the target, etc. One possible way to expedite the time to success on such systems is by engaging with a LabVIEW Embedded Consulting partner.
High level programming models have evolved considerably along the years. With the modern world claim for miniaturization of devices and distributed intelligence, embedded systems are now required to implement constructs that were, up until a few years back, unique to non-embedded systems. However, the embedded execution requirements presented above are serious constraints to the simple porting of such constructs to embedded targets.
The evolution of the so called Cyber Physical Systems is exerting pressure for extra processing and decision making to happen on the nodes closer to the sensors. This pressure is driving the evolution of distributed control and monitoring systems that have been slowly replacing the old client-server paradigm. On the client-server topology, the acquisition nodes had little intelligence. Their main task was to acquire sensor data and push the acquired data to a central data repository located on a server entity, where higher level decisions would then be made and carried out back to the actuator nodes. This architecture requires an amount of data traffic in the network and a level of server data storage that are quickly becoming barriers to the implementation of networked systems that can better adapt to the increased data requirements of the modern Cyber Physical Systems.
This need for more intelligence on the nodes that interface with sensors has driven distributed systems to take advantage of the so called PACs, or Programmable Automation Controllers. PACs are control and monitoring nodes that are usually programmed with higher level languages and usually include higher processing power than the old Programmable Logic Controllers, or PLCs. The selection of the right PAC is driven by the overall application requirements, such as unit cost, CPU horse power, I/O count, acquisition speed, etc. A modern distributed monitoring and control application would then have the following topology.
The NFEs, or Network Front Ends, would be the nodes that locally store the database holding the acquired data by the PACs of that same subnet. Also, the NFE would be the holder of the network time source to be used in the synchronization of all PACs of the same subnet. This topology would allow for easy expandability through the addition of new PACs and even the addition of full subnets of PACs. Each subnet can either have independent time sources for local synchronization of PAC data monitoring and control or be synchronized with other subnets via the addition of the Root NFE that would then be the holder of the synchronization time source for the entire network.
Each application would dictate the level of time synchronization based on its own requirements. This architecture can support no synchronization with each PAC operating independently, as well as synchronization to network severs via IEEE 1588 protocol or even GPS-based synchronization. A PAC can also work standalone without being part of a network of PACs. In that case, the NFE node is not needed and the PAC would store its own acquired data.
Fortunately, there are now several options of Hardware and high level Software environments that can be utilized on the implementation of Cyber Physical Systems on the distributed architecture described above.
Expert LabVIEW Embedded Consulting = Speed to Market
Regardless if your needs are for a standalone embedded product or a distributed embedded control and monitoring system, you need the solution deployed as soon as possible. With today’s ferocious market competition, launching your solution prior to your competitor may drive your entire company success.
At TSXperts we understand these business requirements and have created tools that will expedite the deployment of your application by best leveraging off the shelf options available and taking advantage of the high productivity allowed by National Instruments LabVIEW programming environment. The selection of the specific Hardware platform that will function as the PACs is based on the specific application requirements. For applications that require intense computing power and high I/O count, National Instruments offers the cRIO platform, which includes a embedded controller running a real-time operating system and a FPGA for even more stringent real-time processing requirements.
If higher volumes and lower PAC unit costs are part of the application requirements, National Instruments offers the NI SOM, or System on Module. The NI SOM can be made part of a custom PAC that would be designed to be tailored to the specific application requirements of I/O count, acquisition speed as well as signal conditioning for unit cost reduction. The NI SOM offers real-time capabilities via Linux based RTOS and an FPGA for I/O processing. The off the shelf aspect of the NI SOM reduces a good portion of the technical risks of developing a custom solution; which ends up accelerating the overall development time and reducing Engineering costs. A PAC can be designed to include a Linux based ARM multi-core CPU alongside with the NI SOM for the execution of non-real time tasks such as data storage, network synchronization, user interface GUIs, non-real time control decisions, etc. The developed TSXperts LabVIEW compiler products allow LabVIEW to run embedded on the Linux based ARM CPU of such PAC and NI off the shelf tools allow LabVIEW to also program the real-time NI SOM CPU as well as its FPGA. TSXperts offers Hardware and embedded Software capabilities for the development of these custom PAC solutions.
For applications with moderate computing power requirements, the PAC nodes can also take advantage of the Arduino platform or even a Raspberry Pi single board computer. The Arduino platform includes a Microcontroller for real time application with simple requirements. TSXperts, in conjunction with Aledyne Engineering, created a compiler product that allows LabVIEW to run embedded on Arduino compatible targets. The Raspberry Pi is a single board computer that can run Linux or Windows 10 and can potentially replace the need for higher cost industrial computers that are required in distributed embedded applications. TSXperts is in the process of releasing another compiler product, one that allows LabVIEW to run embedded on Raspberry Pi single board computers, both block diagram and GUI applications. Furthermore, TSXperts has launched an Arduino compatible Hardware target, the PWS, that is Test and Measurement ready and includes on-board real time clock and built-in Wireless capability. The PWS is well suited to function as a simple PAC in the aforementioned platform, and can be fully programmed in LabVIEW.
This allows for a single high level programming environment, LabVIEW, to be used throughout the entire platform, regardless of the application requirements for the embedded nodes. This approach allows full flexibility in the selection of the best embedded hardware for your specific application, minimizing time to market and cost and maximizing re-usability of components and return of your investment. TSXperts offers expert LabVIEW Embedded Consulting services that minimize your time to success and cost of final implementation by leveraging off the shelf tools and utilization of low cost embedded hardware when applicable.
Ultimately, TSXperts can create custom hardware that can also be programmed in LabVIEW and run LabVIEW embedded, tailored to the application requirements, in case off the shelf components are not a option.