Ignition by Inductive Automation is the new Microsoft Excel for manufacturing.
Got a business case that involves data originating from a field device and/or PLC? Throw Ignition at it. Need a P&ID visual of any sort? Good ol’ Ignition will do the trick. Need your process control data pre-processed & transformed? Slap some Ignition on it. Need data pipelines to connect & collect data from the edge? Ignition. Need edge network configuration changes and oversight of said changes? Ignition.
Manufacturing is absolutely addicted to the idea of a monolithic software solution. What may have originally started off with good intentions, Ignition is now becoming synonymous with controls engineering / IIoT = Ignition. This mindset that there should only ever be 1 software product handling every facet of an entire division is wrong and poisonous on so many levels.
Commercial products like Ignition rapidly decrease the time required to deploy solutions for many business needs, which are typically simple CRUD-style apps. This rapid time-to-market cannot be understated, especially for small-medium manufacturers, which lack full-time software developers.
Finagling complexity from off-the-shelf commercial products can be done and the real cost is your dependence upon the product. The nefarious assumption here is that the company selling a proprietary product has the customer’s best interest in mind & will hopefully innovate/adapt to technology trends.
The pace of innovation & change in your company now entirely relies on a single vendor. This is where technical debt rears its ugly head and the true total cost of ownership is now viscerally felt. It is no longer just a theoretical number on a ROI spreadsheet that isn’t worth the paper & electron bytes it’s printed on.
The time spent on trying to force-fit your operations around the product becomes a sunk opportunity cost that would have resulted in higher returns if you instead invested into open-source technologies.
The best part about using open-source technologies is that you own the solutions outright & you change them as you need when you need. Modern-day infrastructure costs are pennies on the dollar and very scalable on all ends. Using commercial products to handle simple needs, like basic CRUD-style apps, is a reasonable level of technical debt to take. Over-leveraging your technical debt into a singular commercial product is a great way to stifle growth & innovation.
The worst part about products like Ignition is they fail to meet their own claims of allowing programmatic access to the product’s back-end. Jython is older than the invention of the wheel and there’s clearly no intention or way for Inductive Automation to ever get away from this dinosaur. Lua, Rust, and more can do what Jython does and already have much larger support. License costs are also no joke with platforms like Ignition. In general, all-purpose IIoT/SCADA products like Ignition, FactoryTalk, TIA Portal, Emerson DeltaV, and so-on are simply products of a bygone era that continues to prove themselves as insufficient and bloated.
Why use a OEM’s proprietary pre-packaged software to configure your field devices & controllers, as well as deploy PLC code & build operations apps when FOSS technologies exist that handle each of these specific functions? FOSS technologies like PLC4X allow app development & network configuration using Java and support many common controllers & field devices, FOSS PLC-code IDE such as OpenPLC, countless Python libraries that handle data pipeline building, Rust to manage embedded hardware programs for electrical design & validation, and beyond are just some of the many options to diversify the tools that manage different facets of your OT environment.
There’s incredibly high levels of unnecessary risk manufacturers take when allowing such monolithic products inside their walls. Breaching into the OT environment today means attackers immediately gain access to a monolithic platform that grants you the ability to manipulate all facets of OT.
The truth of the matter is OT development consists of many specialized functions. There’s network configuration, app development, electrical circuit design & validation, mechanical installation, remote access tools, data engineering, data modeling, IT infrastructure to host apps & data pipelines & data history, IT general controls for PAM-solutions to provision accounts, and more. No one can master all of these areas, especially not with the rapid change of today’s technology. This is why hardware OEM’s should only be trusted to make secure and reliable chipsets with transparent channels of procurement.
To take it a step further, most OEMs make the equipment procurement process an absolute nightmare. Buying a rough pump is not just as simple as buying a rough pump. One would imagine that you could buy hardware easily just as plain hardware without any sort of OS or software. Oddly enough, this can be done with many other industrial hardware products.
Yet when it comes to process equipment, you will be required to purchase the pre-packaged HMI/SCADA-lite software the OEM decided to encapsulate the pump behavior in. You will NOT get an image of the OS and software installed, and you will have to reverse engineer all the control narratives that went into building the hardware you purchased.
At what point in the sales process, then, can you really say you own the equipment? Oftentimes these HMI/SCADA-lite applications are designed using a big-name OEM SCADA solution, which means a license you’ll have to perpetually renew, controls engineering time to decode control narratives, operators to train on a confusing & poorly designed HMI, maintenance/RCM engineer time to decode how to safely shutdown the machine for repairs, and data scientists that need to figure out what scientific compute models were used to model the start-up/equilibrium/idle/shut-down cycles look like.
We need to normalize demanding from machine builders to sell bare equipment with no OS and software installed, lower the cost of purchasing said equipment with no software bundled in, hand over the models they would normally pre-package into the HMI/SCADA-lite software so that we as the customer can use it as we please. This is the only way we can then truly begin to say we are on the path of owning the equipment we buy.
Web App Development & Lowcode Platforms
On this same topic of over-promising and under-delivering, let’s now turn our attention to low-code platforms & web app development.
The need for SaaS-based low-code app development platforms cannot be understated. The hype is definitely real, with the primary driver being a short time to market. The added benefit is these products require no infrastructure management, alleviating a major concern for many small-medium sized manufacturing companies. Again, most small-medium manufacturers do not have full-time software developers in-house & generally cannot afford the high fees of consulting firms to deploy such resources.
With all that being said, current low-code platforms like Tulip, Mendix, Power Platform, Anvil, SAP DMC, and more leave much to be desired. For starters, the underlying technology powering these platforms under the hood is primarily React wrapped with Redux. Both of these technologies are incredibly lightweight. They do not consume much network bandwidth & require very little compute power. Both of these web technologies are very popular yet many low-code platforms fail to offer sufficient programmatic access to the back-end to allow developers to build out additional complexity.
The selling point all low-code platforms state is they can do it all — parse all kinds of data (business flat files, industrial machines, app logic, app state, network logs), instantiate data models & database schemas natively in the platform, build visualization dashboards with data transformation capabilities, build/deploy fully functional applications, and even build API natively in the platform to handle integration to other systems.
Yet when you actually go to use these platforms, they fall short on all of these technical features as well as matching their licensing costs to the level of resources they consume. Testing workflow automation & app functionality in the Power Platform is a nightmare — you must build out an entire replica data schema dedicated just to capture your test data, because it automatically begins writing all data into the production schema. Over 9000 IQ here by Microsoft.
Creating data schemas in Tulip in a programmatic, autonomous way is impossible & they rely on a 3rd-party tool to actually parse flat files to load onto said tables. Loading master data by business users is a daily occurrence.
Building app logic inside Mendix requires a PhD in nuclear physics and chemistry, after which you must then also obtain a fighter jet pilot license to begin navigating the ungodly UI and make any sense on how to find which components do what. Clearly no Mendix has no UI/UX engineers on the team.
SAP DMC is a Node-RED and Power Platform wannabe that does neither well. And by the way, that’ll be $50k annually to use this ridiculously lousy tool.
With frameworks like Refine out there, which allows developers to rapidly deploy React components & countless more frameworks to rapidly build NodeJS backends, it amazes me at how consistently vendors fail to meet the mark. Web app development continues to become exponentially cheaper & easier, yet low-code platforms are doing the opposite. Make it make sense.
I’ll be making a video about all of this soon to expand on each topic in more detail. Stay tuned and I’ll see you in the next one. Thanks for your time.
Follow me
› Linktree: https://linktr.ee/opensourceadvocate
› LinkedIn: https://www.linkedin.com/in/enrimarini
› Substack: https://enrimarini.substack.com/
› Twitter: https://twitter.com/@RealEnriMarini
› Medium: https://medium.com/@TheEthicalEngineer
› YouTube: https://www.youtube.com/@EthicsAndEngineering
› DEV Community: https://dev.to/@opensourceadvocate
› TikTok:https://www.tiktok.com/@opensourceadvocate
—
DISCLAIMER: I am not sponsored or influenced in any way, shape, or form by the companies and products mentioned. This is my own original content, with image credits given as appropriate and necessary.
Top comments (0)