Final Report Summary - SAFETYLON (Development of an interoperable platform technology for safety related data transfer and secure communication in local operating networks)
In the description of work (DoW) the preferred solution was a dual processor architecture whereby one processor was one of the standard LON chips (neuron or NEC LC30x0) serving as communication and application processor, and the secondary, different chip was to perform the role of a redundant processor. Both chips were to check each other's 'sanity' and results. After in-depth research and calculations it became clear that we needed a much more powerful architecture because of the permanent self-testing of hardware and firmware and the bandwith required for interprocessor and I/O communication. The final design specification is characterised by the following features:
- a two channel design for the SAFETYLON protocol based on a duplication of safety frames within a single EN14908 frame;
- an application layer protocol which provides a set of 'safe' services in a 'safety layer' independent of the underlying standard LON protocol;
- a dual safety processor architecture communicating through either a front-end LON chip from Echelon or from Loytec;
- a simple safety scheduler of own design and implementation in order to avoid the complexity and the cost of using a commercial embedded operating system;
- two functionally identical core modules from two industrial RTDs (WHO and Loytec) to provide a ready to use platform for SME applications;
- choice of either a commercial or a public domain application development environment which will increase the acceptance and ease of use for SMEs;
- employing an enhanced version of available commercial tools in combination with a verification method of safe installation parameters.
The new three processor architecture is decidedly more powerful and in many ways superior to the DoW proposed design. In particular, the SME safety applications will now be identical for both hardware platforms and even the safety firmware will be identical. It turned out, however, that the implementation will require significantly more time and resources than originally planned. This concerns primarily the three RTDs who are responsible for the design and development of the core functionality, i.e. Innotec, ICT and FH Dortmund. In order to compensate for these unplanned efforts the entire work plan was reworked and some critical paths could be eliminated. To be on the safe side, though, it may occur that the project end date may have to be extended by up to three months.