If you don't have people coming out of the industrial automation space with a good understanding, it's hard to walk back in with a useful product.
Sorry for the runon but this is a major gripe of mine. Most managers just want it to work and unless it doubles your profit, cuts failures and makes you coffee for when other stuff breaks and you're working overtime to fix it they don't want to change anything.
I can sympathize, and I bet you can too. My dishwasher, my car, my garage door... I just want these things to do their job and let me get on with my actual work. I don't want the latest garage door or vacuum.
If the whole point of the organization is to build things, it seems like they should use the best tools for building things. Now, there's a good argument for tried and true solutions, and if the new stuff isn't rock solid, you're going to have wasted materials. It really seems like they should be completely geeking out over better, shinier, fancier tools for building stuff.
Maybe the costs are so high, and the margins so thin there's no room at all for experimentation. But it can't be lack of desire. If it is indeed lack of desire, they're going to go out of business.
I meant identifying the problem and coming up with a solution in the first place.
Go to market is another level of complexity.
From what I've seen (relatively minimal), industrial automation tends to be incredibly bespoke. E.g. we had consultant X from Y integrator (sometimes now defunct) come in Z years ago (where Z is always > 10) and set up this system: we've been using it as a black box without change since.
In short the "Linux on the desktop" problem - the burden of having to support 1,000+ unique configurations, each with their own edge case behaviors (or outright bugs). And from what I've seen, the ideal startup growth pattern doesn't fit with a services "send one engineer out to an account to custom fix it" way of doing things.
This is accurate and it stems from the proprietary technologies that integrators must sew together. Want to build a better Siemens Step 7 IDE? Get a job at Siemens.
Best case, with clearly documented and defined interfaces, you can rewrite or swap out an entire component. Worst case, you have no source, no standard technologies, and no interface barriers, in which case your choices are leave as-is (no additional features) or replace everything (impractical due to size of codebase / legacy functionality coverage).
As a software engineer that works in this space, I disagree. The thing that keeps us using things like MODBUS and CAN are because the problems we are solving are themselves are very simple. So we tend to use simple solutions to address them. The latest dynamic languages and protocols (XML, JSON, YAML, etc) don't solve our existing problems any better.
Quite frankly, the extreme level of complexity in deploying something like Android to control a basic IoT device is beyond appalling. 640k may not be enough for everyone, but it is more than plenty to control IoT devices.
The upside is a lack of competition and a B2B environment. No need for a marketing department when you just have to attend a few industry trade shows a year.
Even if FactoryTalk is absolutely horrid.
As a software engineer, I always thought that the best way to have a great business (not a blow out VC style business, but a good business) is to be a decent-to-good software developer and have deep domain knowledge of some other industry. I thought the best way to get that would be to apprentice in that industry, but the opportunity cost is high (esp as you get older), so the second best way may be to take a job as a dev in that industry and learn as much as you can from the domain experts.
The combo of software development + domain expertise means you see problems to automate away all around you and you can actually execute on what you see.