I am very interested in this topic. Although I am new to the Rust language (I came across it during research about languages that will be real-time compatible), I think that what @birkenfeld has put together is already an interesting start, and I am going to try and get it to run soon (once I can get some hardware).
I have been working in the industrial automation world for about 10 years now across several different industries, and the problems remain the same (code testing, speed of deployment, data access), but the solutions introduced by major vendors such as Siemens, Rockwell and even Beckhoff are lacking. I have talked with executives from all three companies, and they don’t take the conversations about open access or applying modern software principles to their platforms seriously (or at least their priority for such features is very low). It is quite frustrating.
There are a few half-started projects for open PLCs, see for instance OpenPLC, Beremiz, matiec, 4DIAC. I think part of the issue is there is not a big enough crowd of end users to keep an open-source project going, and with the lack of access to hardware, it makes it difficult to gain any traction. If you look at the embedded world as a similar example, each major vendor such as Atmel, Broadcom, STMicroelectronics all sell or provide free IDEs, which have the same problems a PLC IDE has - lack of good testing tools, crappy, unmaintained user interfaces, poor code automation support, etc. But the embedded world has seen the rise of tools and frameworks like PlatformIO, Arduino, mBed OS, etc which are slowly changing the equation and making it possible to target different hardware without relying on the vendors IDE and tools. I wish the same was true in industrial automation.
One thing I think would help with adoption is if the runtime is abstracted completely from the hardware, such that, by default, it is always possible to run the program with hardware disconnected. For instance, with EtherCAT, it should be possible to run the control software without the EtherLab driver installed, by using a mocked out I/O image that can be manipulated through software. It would be OK in this scenario to not meet any real-time constraints - e.g. the control software is designed to execute cyclically in bounded time during production, but perfectly acceptable to not meet these requirements in a testing / virtual environment.