Navigating the Future:

Delve into this technical whitepaper exploring the concept of modernizing the native LabVIEW applications by addressing the key challenges in continuing with the native applications, the inherent need for modernizing it, and a “service-oriented architecture” approach to aid you in modernizing your application, explained with an in-depth example. 

With technology evolving at an unprecedented rate, the need for adaptability and innovation has become paramount for industries to thrive in this competitive landscape. In this context, legacy systems can sometimes hinder the vision of the company, necessitating the need for enhancing the legacy systems with better cutting-edge solutions.  

LabVIEW, a stalwart in the realm of engineering and scientific applications, has been a driving force behind automation and control systems in industries such as automobile, mechanical, production, and manufacturing. However, the rapid progression of technology beckons for a paradigm shift, urging us to explore novel approaches that enhance the efficiency, scalability, and flexibility of LabVIEW applications. 

Let us now take a deeper dive into the functioning of the LabVIEW application in the real world with examples and illustrations. We’ll also see the need for modernization and the prime ideals behind it that can help transform your legacy application into a more robust, scalable, future-proof application.  

Example of a LabVIEW Application Explained with an Illustration 

Applications built on LabVIEW can be found in a series of contexts for a variety of purposes, streamlining complex operations across various domains.  Throughout this article, we will consider an example of a pencil-sorting automation system to visualize the challenges with the native application and how we can modernize it. 

The objective of the pencil-sorting automation system is to sort and categorize a series of pencils that are moving in a conveyor. The pencil array consists of three colors – red, green, and black and will be sorted into three different buckets based on their colors.  

The setup contains a high-speed camera that captures the images of the pencils coming along a conveyor. An image processing unit analyzes the captured images and decides the color of the pencil. Three actuators are placed one after another, one for each color will push the appropriate pencil out of the conveyor. The pencil that goes out is transferred to another conveyor, where it is collected in a separate bucket. In this way, pencils are categorized and sorted into three different buckets with the help of 3 actuators and a camera. 

The LabVIEW application here serves as the central controlling unit for the entire setup. The application receives the images of the pencils from the camera and performs the image processing to decide the color of the pencil. Based on the color, it sends signals to the appropriate actuator to push the pencil out of the conveyor. 

Here is a video to give you a glimpse of the working of the Pencil-Sorting Automation System built by Soliton.

In essence, LabVIEW applications act as efficient coordinators in intricate industrial environments. They manage the seamless integration of diverse components, ensuring precision and adaptability in real-world applications. 

Building the Native Applications: Monolithic Approach vs Plugin Based Approach 

The development of Native LabVIEW applications follows two fundamental paradigms: the monolithic approach and the plugin-based approach.  

The Monolithic Approach 

The first encompasses a monolithic application, designed explicitly to control a fixed system.  

In the earlier mentioned example, the entire pencil-sorting system would be controlled by a monolithic LabVIEW application. Any changes made to the system, such as integrating a new image processing unit for improved efficiency, deploying a higher-resolution camera, or integrating a new data logger module to log the pencil count, necessitates a comprehensive reworking of the entire LabVIEW application, which will result in more time. This monolithic approach is not scalable and modular, as it involves the rework of the application even if there is a simple change to the system. 

The Plugin-Based Approach 

To avoid this challenge, a transition to plugin-based systems has proven to be instrumental. A plugin-based architecture is a design approach that allows a software application to be extended and customized using plugins or modules. In this architecture, the core functionality of the application is kept separate from the additional features or functionalities provided by plugins. Each plugin typically encapsulates a specific set of features and can be dynamically loaded or unloaded at runtime. In this model, each functional module assumes the form of a LabVIEW plugin., while the main LabVIEW application controls these plugins.  

Referring back to the above-mentioned example, different tasks, such as image capturing, image processing, actuator control, and conveyor control, are governed by distinct plug-ins. The LabVIEW framework contains all these plugins and an orchestrator. The orchestrator creates a seamless flow of data between all these plugins to form a complete workflow.  

This happens via the framework that creates communication channels between the plugins to enable data transfer between them. So, the image capture plugin will transfer the images captured to the image processing plugin, and this, in turn, will decide the color of the pencil and transfer this information to the actuator plugin. The actuator plugin, after receiving the color, will activate the appropriate actuator to help sort the pencil. This facilitates modifications in the actual setup, where new plugins can be developed, or existing ones can be modified to accommodate changes while the main LabVIEW application remains unchanged. 

Now when a new image processing unit is required, a new plugin can be developed and deployed without affecting other plugins or the main application. The addition of any new functionality, like data logging, can be developed as a new plugin. The orchestrator will facilitate the communication between other plugins and the data log plugin for it to log the data. 

The modular and plugin-based nature of this framework renders it universally deployable across diverse applications and systems, that involve multiple units communicating with each other to perform a task, configuring the data flow within the established framework. This adaptability positions the framework as a versatile solution for a spectrum of use cases. 

Key Challenges in Continuing with the Native LabVIEW Application 

Having a look into the construction of native LabVIEW applications, there might be some challenges that loom on the horizon of the legacy applications. These challenges prompt a rethinking of established practices and underscore the importance of addressing limitations. Let’s now see three key hurdles that signify the need for a more innovative approach to LabVIEW applications. 

Constraints on Programming Languages 

LabVIEW, being a graphical programming language, has its own advantages over text-based languages. Still, certain text-based languages have their edge over LabVIEW as they benefit from extensive libraries readily available for several use cases like Machine learning, Data science, web development, scientific computing, Artificial intelligence, etc. 

If an engineer needs to develop a plugin in Python, C#, or a specific language based on the use case and need, this current architecture might not support it.  

Ideally, the best solution would be to develop plugins in a programming language that is best suited for the functionality of the module, and the main application should still support the data transfer between them. 

Constraints on Platform or Operating System 

Current LabVIEW applications are platform-dependent. Predominantly, LabVIEW applications are Windows-based. This nature of LabVIEW applications contributes to a platform dependency that limits their adaptability and hinders their flexibility across a spectrum of hardware and software environments. 

If any plugin requires execution in any other operating system (for example: Linux) or on any other operating system, it becomes tricky and difficult to execute. 

Constraints on a Closed System 

For optimal functioning, it is common that the workflow, including the application, instruments, and operating system, might be distributed over multiple workstations or in the cloud. These legacy applications also operated within closed systems that require the whole workflow and process to be managed from a single unit.  

These challenges underscore the imperative for a more dynamic and adaptable framework, addressing the evolving landscape of technology and system requirements. 

The Need for Modernization 

In modern industrial systems, complexity is inherent and is characterized by numerous interconnected devices and intricate processes. This demands flexibility in the development, control, and maintenance of application modules and components to navigate this intricacy. While these LabVIEW applications aptly address immediate needs, a pertinent question arises: Are they future-proof? Do they possess the scalability and modularity required to adeptly accommodate the evolving and dynamic demands across diverse industries? The unequivocal answer is a resounding call for enhancement and adaptation. 

Shaping LabVIEW Applications with our Modernization Goals 

As we confront the limitations of current LabVIEW applications in meeting the evolving demands of industrial systems, the imperative need for modernization becomes evident. To propel LabVIEW into a more adaptive and scalable application, we’d have to focus on certain modernization goals with a specific focus. These goals not only address the immediate challenges but also lay the foundation for a future-ready paradigm. Let’s delve into the key modernization goals poised to redefine the landscape of LabVIEW applications. 

• Develop a flexible LabVIEW framework that supports modules from any programming language and implement modular designs facilitating the integration of emerging technologies. 
• The main framework should support plugins across various operating systems such as Windows, Linux, embedded systems, or any other operating system based on the use case. 
• Build reliable applications capable of continuous data acquisition, edge/cloud analysis, algorithm execution, and post-processing tasks that can operate for extended durations. 
• Foster easy migration to advancing technologies at intervals of every 5 to 7 years. 
• Develop scalable and easily deployable components for computation, aligning with cloud computing paradigms, allowing for dynamic resource allocation, optimizing resource usage, and minimizing costs associated with overprovisioning. 

These modernization goals collectively serve as the blueprint for reshaping LabVIEW applications, propelling them into a domain of heightened adaptability and sustainability. 

Service-Based Architecture for Modernizing Native LabVIEW Applications 

Transitioning from the discussion on the need for modernization, a pivotal approach lies in adopting a Service-Oriented Architecture (SOA). SOA, a design paradigm structuring software components as independent and deployable services, emerges as a transformative solution. Each module or component becomes a separate service, and a main framework facilitates communication between these services. The objective is to enhance flexibility, scalability, and interoperability, addressing the evolving demands of complex systems. 

In the context of the earlier example, SOA facilitates the development of individual plugins as independent services, transcending the constraints of programming languages or platforms. These services seamlessly operate across diverse environments, be it cloud or edge systems, while the central framework oversees the flow of data and communication between these services.  

Putting it in simpler, easily understandable terms, the plugin-based pencil-sorting automation system will be transformed into a more modernized system as follows: 

• The enhanced system would contain services running for each functionality and purpose. That is, there will be a camera service that captures images, an image processing service to process and analyze the captured images, and an actuator control service to control the movement of actuators. 
• A Web dashboard service to display the count of plugins in a web browser can be added. 
• These services can be developed in any programming language, and they can run on any operating system that is best suited for its functionality. 
• The services can also run on any platform, be it Edge or Cloud, based on the need.  
• The main framework will just list all the running services by identifying them, facilitating the data flow between the services. 
• The camera service that sends images does not know which service it is sending the data. All it knows is a “To Address” to which it needs to send the data. The main framework assigns this “To Address” to the camera service. 
• The Image Processing service that is receiving the images does not know from which service it is receiving. All it expects is images in a specific format.  
• In this way, all services are independent. Individual services can be modified, and new services can be deployed without affecting the other services and the main framework. 
• In simple words, the main framework plays the role of a postman that knows the “From” and “To” addresses of all services. It carries messages from one service to another through a communication channel.  
• Also, the main framework does not worry about the programming language or the operating system of any service. It just needs the address of the service which it can use for communication. 

Key Pillars of the Service-Oriented Architecture 

To give more detail to the SOA architecture that tackles all the modernization challenges persisting in the legacy applications, let us now see how by recalling the above example of the pencil-sorting system: 

Language Agnosticism 

SOA accommodates diverse programming languages within individual services, endorsing a language-agnostic approach. The modular nature allows the use of LabVIEW or any other programming language, promoting flexibility. 

Consider the above-mentioned example. The service that needs to acquire data from a camera or any sensor, can be developed in LabVIEW since LabVIEW has a wide variety of instrument driver support. This LabVIEW service can then transfer the captured images to an image processing service that is developed in Python. Python has a wide variety of image-processing libraries so this can be the best fit for image-processing needs. The central framework can discover the running services despite them being written in any programming language.  

Cross-Platform Compatibility 

Services developed under SOA can operate on various platforms—Windows, Linux, or other dedicated embedded systems. This adaptability ensures optimal performance and functionality, as is exemplified in the scenario where image capture and processing services run on different machines within the same network. 

Going with the same example, the camera service that captures images at a specific rate is a LabVIEW service and can run on a Windows machine. All the image processing services, that are developed in Python, might need machines with high computing power and processing speed. They cannot run on the same machine where the image is being captured, as it might affect the processing speed. So, these services ought to run on a different dedicated Linux machine with high performance to achieve processing speed. All the machines running these services are on the same network so that the main framework can facilitate communication between these services. 

Reliable Systems 

SOA’s loosely coupled design ensures the independent operation of services, minimizing the impact of failures on the overall system. In a production or manufacturing floor, systems must run for weeks and months. Software is prone to crashes and failures. In SOA, if one service experiences a failure, it doesn’t cascade to other services. There are crash recovery mechanisms employed within the services to keep them up and running without affecting the other services. In this way, the production or manufacturing floor process is not affected, and the software can run for months.  

Migration Friendly 

SOA’s modular and interoperable structure makes it inherently migration-friendly to changing technologies. The framework’s emphasis on loose coupling and adaptability facilitates the seamless integration of new programming languages with advanced control and security capabilities that come out in the future, without necessitating a complete overhaul of the existing system. It also promotes interoperability, allowing services to communicate seamlessly despite differences in programming languages, making it easier to adopt emerging  

Cloud Friendly 

SOA’s modular structure aligns seamlessly with cloud computing, treating individual services as independent components. Using Cloud providers, we can deploy, and scale individual services independently based on demand, optimizing resource utilization. Each service can run in its own container or virtual machine, providing isolation and enhancing resource efficiency. Moreover, complex processing and analysis services, that require dedicated machines with high performance can be run on cloud systems.   

In industries, there are going to be needs that require applications to process huge amounts of data and give out results in a short time. Referring to the example, in the future, pencil production will increase due to growing demands. So, the categorization and sorting of pencils must happen faster to make sure more pencils can reach the market quickly. For this to happen, the application must capture images at a faster rate and process the images quickly. This can be achieved by running the services associated with these functionalities in the cloud. The services can scale up based on the demand and can execute faster to process the results. 

In essence, SOA emerges not just as an architectural shift but a strategic move towards future-proofing LabVIEW applications, ensuring they remain agile, scalable, and adaptive in the face of evolving technological landscapes. 

Concluding the Modernization Endeavor 

In conclusion, the modernization of native LabVIEW applications and frameworks stands as a strategic imperative, ensuring their continued significance amid the dynamic shifts in the technological landscape.  

This isn’t merely a technical upgrade; it represents a strategic move to fortify operations against the ever-evolving future. Through the adoption of a tech-agnostic and platform-independent approach, these applications gain the resilience needed to adapt to emerging technologies, fostering a culture of continual innovation and operational efficiency.  

At Soliton, we believe in the tech-agnostic approach promoted by this modernization effort that emancipates LabVIEW applications from the technology dependencies, paving the way for seamless integration of new tools and methodologies. And this strategic shift safeguards the enduring relevance and adaptability of LabVIEW applications in a rapidly transforming technological terrain.