Re: Why the fcuk...
"I remember MAP/TOP. [snip see later] It was supposed to be a competitor to Ethernet,"
Then I'm afraid you remember it a bit wrong, but as I said, reference material is hard to find. The original MAP people included a group of lower layer companies whose names I forget and can't easily find, who were obsessed with having MAP based on 802.4 token bus cables and interfaces, which was a generally daft idea (unless you were an 802.4 vendor).
Siemens and many other sensible outfits said "we can do this using industrial strength Ethernet". Siemens as far as I know went ahead with their AP protocol suite over Ethernet, addressing exactly the MAP requirements. Computer vendors such as DEC would happily talk to either or both, using the same software.
"Each [automation] vendor had its own hardware, peripherals, OS, programming languages, and development tools, and guarded "their" customers jealously. "
Exactly, and that is exactly what MAP and TOP were supposed to address (cabling aside).
The important bits were not how the devices were physically connected (802.3 vs 802.4), but what the connection allowed you to do, in a device-independent, vendor-independent, interoperable manner (without the lock-in which otherwise arises, which you clearly recognise). Sadly, lots of people failed to see beyond the cabling.
The MAP/TOP idea was that if you didn't play according to the MAP/TOP rules set by GM, Boeing, and other significant automation purchasers, you didn't sell automation (devices or applications) to them. Once you've got standardised interfaces and protocols, the rest becomes relatively simple.
"It was a flop".
It was undeniably a flop in commercial terms. It addressed a device<->application integration (not cabling) problem that most people with chequebooks didn't see a need to fix, and those that saw the need didn't like the price at the time. You clearly see the problem. Maybe now computers and networks are cheaper, the people with the chequebooks would appreciate the situation too.
"For exchanging data between the factory floor and the IT systems (e.g. ERP), what's really needed is something like an HTTP REST protocol with JSON data."
Maybe. But I hope you're not suggesting putting that functionality in the factory floor devices and making it directly accessible from the corporate desktops. There lies anarchy. On the other hand it could quite happily fit in a secure "shop floor gateway" box which has the shop floor kit on one side and the corporate network on the other side and some clever software in the middle.
These boxes were around in the late 1980s, using MAP protocols (sometimes over 802.3, sometimes over 802.4), Siemens AP over 802.3, and other proprietary protocols (such as the inevitable Modbus).
Back then, this kind of functionality required minicomputer or workstation class hardware and a real OS (this is before Windows NT) to do a worthwhile job. There were similar compute requirements in the network interface+software in the automation device. It didn't stand much chance of success. Collectively this led to interesting oddnesses like Allen Bradley putting a rebadged VAX in the same backplane as a high end PLC (the Pyramid Integrator) so your enterprise apps (which weren't called that back then) could run on the shop floor boxes.
Compute power and network performance is not the problem it was back in the 80s, and the alternatives to Windows are more acceptable these days (or should be) than they have been for a decade or two.
Sometimes the solution is there, waiting for you. Or at least it might have lessons to offer to those who might be tempted to re-invent a few wheels.
Some of the people who did the useful work in the 1980s might not have retired yet, if you're quick.
Biting the hand that feeds IT
