AQ: Electronic industry standards
You know standards for the electronic industry have been around for decades, so each of the interfaces we have discussed does have a standard. Those standards may be revised but will still be used by all segments of our respective engineering disciplines.
Note for example back in the early 1990s many big companies HP, Boeing, Honeywell … formed a standards board and developed the Software standards( basic recommendations) for software practices for programming of flight systems. It was not the government it was the industry that took on the effort. The recommendations are still used. So an effort is first needed by a meeting of the minds in the industry.
Now we have plenty of standards on the books for the industry, RS-422, RS-232, 802.1 … and the list goes on and on. The point is most of the companies are conforming to standards that may have been the preferred method when that product was developed.
In the discussion I have not seen what the top preferred interfaces are. I know in many of the developments I have been involved in we ended up using protocol converters, Rs-232 to 802.3, 422 to 485 … that’s the way it’s been in control systems, monitoring systems, Launch systems and factory automation. And in a few projects no technology existed for the interface layer, had to build from scratch. Note the evolution of ARPA net to Ethernet to the many variations that are available today.
So for the short hall if I wanted to be more comparative I would use multiple interfaces on my hardware say usb, wireless, and 422. Note for new developments. With the advancement in PSOCS and other forms of program logic interface solutions are available to the engineer.
Start the interface standards with the system engineers and a little research on the characteristic of the many automation components and select the ones that comply with the goals and the ones that don’t will eventually become obsolete. If anything, work on some system standards. If the customer is defining the system loan him a systems engineer, and make the case for the devises your system or box can support, if you find your product falls short build a new version. Team with other automation companies on projects and learn from each other. It’s easy to find issues as to why you can’t succeed because of product differences, so break down the issues into manageable objectives and solve one issue at a time. As they say divide and concur.
