New software products hit the market every single week. Most fulfill specialized purposes and it seems like most are targeted at the Oil & Gas industry. But it makes me wonder, how many of these packages are developed from the ground up?
We talk about "the platform" all the time. A platform is sort of like an operating system but higher up the software stack. Why would you recreate deployment , development, security, licensing, connectivity , authentication, management and monitoring logic repeatedly when all of this could be part of a platform? For example, with our product, all the non-specialized stuff is handled by the platform while "modules" handle the specialized part. This allows module developers to concentrate on solving the problem and not the mundane stuff that's already been done before.
Let's look at what the Ignition platform actually does... It is an OPU-UA Client. It's really smart about databases in that it knows how to talk to a wide variety of them even with their subtle (or not so subtle) differences. It optimizes database requests, handles database failover logic, handles store and forward logic, and far more. It is also a web server and handles all the complicated details of client deployment, client communication, application synchronization and more. It handles all the details of the unified development environment (yes, one environment for developing/ configuring any module installed in the platform). It handles redundancy, system logging, auditing, alarming, security, authentication, licensing, the scripting engine, and if I listed everything else this post would be pages long. The point is, 98% of your job is done when you leverage the platform. And the point is, you know 98% will work as advertised so you can concentrate on the real problem you are trying to solve.
Most of the systems that are developed from the ground up are doomed to fail. This is because they reinvent the wheel and with that comes a very long runway and an overwhelming amount of shaking out and fixing. Most users aren't that patient so the undertaking fails.
This blog is dedicated to open, interoperable manufacturing software and the coolest, latest and greatest things I see every day while conducting business under the banner of Inductive Automation.
Hello, my name is Steve Hechtman and I am president of Inductive Automation. During the span of one day there is more excitement, more discovery than I can possibly keep to myself. This blog is, therefore, my outlet. WARNING: This site is highly biased in favor of the most powerful, affordable manufacturing software in the world - Ignition by Inductive Automation!
The newly released SECS/GEM driver for the semiconductor industry has been improved! It now supports SECS-I (serial). The first release only supported HSMS (Ethernet) messaging, but as it turns out, there is still a lot of legacy equipment out there and most of it only supports SECS-I communications. You would think this to be a simple thing to implement but it wasn't that easy.
TCP/IP has a lot of stuff built into it that gets leveraged for HSMS but when you get to SECS-I serial you lose that and you've got to build a lot of stuff from the ground up. But that's been done now and the new SECS/GEM module can now be downloaded from our module marketplace.
We are in the process of adding simulator functionality to the SECS/GEM module as well, so that testing and development can be done in the absence of actual equipment and so that equipment definition files can be tested.
The SECS/GEM module plugs right into the Ignition Gateway to provide seamless connectivity between tools, databases, GUI front-ends, ERP systems and more.