What will the factory of the future look like? Let's start with Intel, Red Hat, and 5G Adding robots or automating machines in old factories isn't as easy as it sounds. Retrofitting factories with new technologies for machines and robots to operate in sync requires a new system architecture. Many tech companies are trying to fill that gap with hardware and software. Cloud companies, chip makers, software …
The context of the use of radio seems to be with automated shuttles that carry work in progress between work cells, or automated lift trucks in warehouses. These applications have used radio communications for years, for obvious reasons.
Typical communications would be to tell a shuttle to pick up a load at work cell number 15 and drop it off at work cell 9. The shuttle will have certain paths programmed into it and it will select the appropriate one to take. If you tell it to do something it hasn't been taught how to do, then it won't do it. Safety is handled at a lower level than routing because the assumption is that there will be software bugs and routing misinformation just due to human error.
It sounds like the proposal here is to use existing commercial standards and kit and adapt it to industrial applications instead of creating completely custom designs.
For indoor applications it will be pretty difficult to get a rogue transmitter outside the building within range of a receiver inside the building, given that most buildings are steel and the factory is full of large lumps of steel and aluminum. Someone could of course use a very powerful transmitter, but that would be pretty obvious to anyone looking for it. You might be able to DDOS (or simply jam) a system until your transmitter is found, but that's probably about it.
You would have a sensor for it because whilst it may not be relevant at this time and in this scenario, it may well be relevant to some other case or indeed future project. Its data may also become relevant further down the line and you may require its history to make sense of the new requirement, glad you've got now eh.
It depends how accessible the sensor is once the machine is built.
Adding the sensor at the beginning minimises system downtime should it be needed in the future, since (in principle) said system doesn't need to be taken offline for ages while that sensor is retrofittted to everything that needs it. Just down long enough for the software patch and testing, then carry on.
But yeah, if you know you'll never need that sensor, just leave it out from day one.
>You would have a sensor for it because whilst it may not be relevant at this time and in this scenario
For some reason the ozone sensor on a NASA earth watch satellite comes to mind; never used until someone actually took the time to look at the data and understood the phenomenon it was recording...
" .. Intel chips optimizes data flow by cutting off irrelevant data"
Also, I'm having a heard time with the idea of using a "chip" to filter data which could be more flexibly done using some software. Add to that that it's not just any chips but "Intel chips", and it starts to sound like a solution in need of a problem. Intel needs to remember that its future lies in being competitive, not on relying on customers having to buy its products just because. Start by firing any bean counters who don't get that and backslide into the "old way".
Not even mentioned is the risk loss of IP and information with competitive value, not to mention the risk of loss of machine control and ransomware.
My experience in East Asia (up to about 10 years ago) was that every electronic manufacturer had no external connection with any internal machines, and generally kept internal machines separated into groups. All laptops coming into the premises with 3rd party technicians had to be scanned for viruses every day upon entry, and one place even had some theater about checking disk capacity on the way out to "ensure" no attempted data theft. Which meant loading up with data ballast before entering and deleting just enough of that ballast to compensate for any diagnostic data that needed to be carried out.
I have had clients in this space over the years, and I wish the best for anyone who actually thinks there will ever be "One Size" for anything.
A factory floor tends to be a hodgepodge of technologies, frequently from several decadal generations. There will be stuff linked with PicLan, serial interfaces in four different flavors, and a clever mix of Ethernet and optical network protocols and speeds. Most will have a varnish layer where the manufacturer will have duct taped a ip/http module to a 40 year old design to make a shim to allow management over a conventional LAN. If it has WiFi, it will be 2.4ghz only, and may be an ancient 802.11 G connection. It may use POF(plastic optical fiber, which is actually not terrible because it's electrically isolated and cheap to fix cuts when a forklift snags it) or glass fiber.
Even then, it could be HTTP, SNMP, or some other application layer word salad once you get it all connected.
I will say that standardizing on a Linux platform as the interface layer has some real benefits. It means that you can build a system that is "Sane and Secure" above that level, and if the only thing the floor machines are connected to is a Linux box it reduces the chances of a SCADA attack significantly. It also means that the public interface layer is on a device the client controls and can patch. Good luck finding a patch for the embedded web server from a 25yo mixing tank.
One final benefit is that Linux is heavily used in embedded systems, so many of the engineers are familiar with it, and in many cases it will be a Linux controller inside the tool talking to a Linux server.
As for Bosh and Siemens, they will do everything in their power to keep screwing up the world. The haven't gotten their act together on their own, and they never will. It will take a competitor starting to push them out of their customers sites to get their attention. Too many years of complacency there, though pride before a fall right?
With Siemens, they are the biggest player in industrial automation and their approach is to have a closed ecosystem where you buy everything from them and they only allow a few selected partners to sell kit that works with their stuff. They're like how IBM used to be in the mainframe days. They will develop and sell their own system for this market if it looks useful. At one time they even had their own Linux distro for industrial systems, although I think they discontinued it years ago.
As for your description of the typical factory floor, it's spot on. A typical factory is a hodge podge of technologies spanning decades. When equipment even offers any networking ability at all, it's usually through proprietary protocols and even proprietary electrical standards and cables. An attempt was made at standardization some years ago, but it's a joke as the "standard" ended up being just declaring all the major vendors' proprietary kit to be "standard".
There are a number of companies whose business is just making kit to connect incompatible systems together. The results are generally both expensive and unsatisfactory.
I'd guess probably not.There's already a rich ecosystem of industrial network protocols but the people who wrote this article (and the various marketing press releases) are probably unaware of what's out there, how it all works and what are its advantages and shortcomings.
One communication medium that's unlikely to be used on the production floor is wireless. I've actually prototyped wireless interfaces on some servo drives (real ones, not the sort you'd use for R/C model control)(yes, they're real servos....but.....trust me.....). Apart from all the questions about security and reliability the big issue is that when you're communicating with something that implements motion you really need a level of reliability and certainty that wireless just won't give you. You're better off with a network cable. It also makes the factory maintenance staff's life a lot easier.
This could be a long post but if we're talking industry and the 'word salad' of protocols I'd need to see at least a smattering of words like "CAN" (more likely CAN/Open), Modbus, Sercos, EtherCAT and so on, collectively known as fiedbuses' There's an attempt to integrate everything into a "Common Industrial Protocol" but that looks awfully like yet another attempt to impress OSI on top of networking solutions. (OSI networking, "the one true network", is an early attempt to define the entirety of networking, you'll most likely meed it with the "7 layers" that everyone learns about it. Attempts to implement it have always ended in disaster.)
One change that was mentioned that would be welcome is to move to Linux. Currently a lot of industrial automation applications run on Windows. This gives rise to all sorts of issues because you just cannot update industrial systems every five minutes (or even every Tuesday). Added to that manufacturers have been known to hack versions of Windows to achieve proper real-time behaviour or implement rather dreadful hacks such as VxWin (a marriage of VxWorks and Windows running on a subkernel). Perhaps modern versions of Windows that incorporate Linux would be suitable as a base but I'd be a lot happier if it was a Linux base that was running with Windows on top of it rather than the other way around.
Adding robots or automating machines in old factories isn't as easy as it sounds. Retrofitting factories with new technologies for machines and robots to operate in sync requires a new system architecture.
We had all this back in the mid-1980's with CIM and decided in many cases not to bother and simply implement MRP, followed by MRP2 and MRP3...
The only problem I can see is that the vast majority of those with relevant experience are now 60+
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
