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.
I see two big problems here.
The first is, what's the business case for the buyer? What tangible improvement in their business is possible with all this new technology? Maybe less downtime? Predictive failure models? I feel like the tech is so disruptive, you'd be better off building a completely new factory from scratch rather than convincing an existing one to adopt such a radical process/ops change.
Second, there is a profound skepticism for large-scale software projects in true "industry". My father worked for a long time at Andrew, a maker of coaxial cable in Illinois, which was later acquired by Commscope; their view of software projects was a lot like war in 1984: a constant, ongoing struggle, with no end in sight, of huge promises and lack of good delivery. I'm not sure whether that means the barrier to entry is huge, or once you make great software you'll have a massive differentiated advantage -- probably both -- but just understand, these guys have spent their career dealing with vendors selling overpriced junk from Oracle, SAP, etc. and just expect things will fail from the getgo.
1) I assume you're referring to "Splunk for factories". You could make the same claim about plain-old Splunk. One business case is better real-time response to failure and later, better forensics. I agree, there are many factories where the process is perfected and the operators can read the tea leaves when something goes wrong. Another business case, and probably a better one, might be report generation for managers - people hate making the same reports over and over again.
2) Industrial software largely sucks now. But software in general sucked 20 years ago, and has improved much since then. True industry is behind the software curve by 10-20 years, so they are using old, bad (by today's standards) software. The thing is we've already improved that old, bad software - they just haven't adopted it yet. Once industry begins adopting "newer" software (think Java, .NET, web services) and they see the falling development costs and better features, they get behind it.
There is also a talent shortage in industrial software, because there are higher wages and better working conditions in the desktop, web, and mobile industries. However what has happened is we are now in diminishing returns in those latter three industries because they are saturated with talent, while all the cool things we've built to service those industries can now be repurposed by hard tech. It's the reverse of what happened after the Cold War ended and defense industry veterans fled for greener pastures in Silicon Valley.
You would also have a hard time convincing the buyers to not use the manufacturer software and instead use yours.
Haven't ThingWorx solved this problem very well already ?
I'd like to see better support for actuation in terms of being able to audit things and feed that back to design decisions, which ties very much back to aggregation.
I'm biased to think there may not be much difference between the two domains. And it should be pretty clear that machine learning is going to be increasingly important.
This being said, the customers may not be all that ready for it.
I think making a hard tech product for consumers is still very hard, and those who succeed should be commended. People wanting to dip their toes in the water might consider things like building a factory management portal like Splunk that aggregates sensor data, or something that involves sensing and reporting rather than actuation. Actuation can be dangerous and therefore legally risky.