58
FEATURE
Cross Acceptance of Systems and Equipment CLIVE KESSELL
T
he lengthy time taken to get new projects, systems and equipment into service is something that gives many of us a sense of despair. It never used to be like that, so what has happened to make things so complicated and what can be done to speed things up? Part of the problem is that legislation has been introduced at both UK and European levels that imposes a series of rigorous checks to ensure systems are safe, secure and reliable. From this, a whole industry has grown up to independently verify all of these checks and certify a general ‘fit for purpose’. Is it all overkill and does it have significant cost implications that cause projects to be more expensive than they need be? Two associated articles in this edition (RIA Conference and DfT Session) give a general concern as to the level of bureaucracy that has crept into the business of delivering successful projects. To try and put some of this into context, Professor Rod Muttram recently delivered a lecture to the IRSE on the subject of Cross Acceptance. He attempted to explain how it can be a positive influence for the introduction of new technology, but he also set out how difficult it can be for all parties to buy into the whole process.
Rail Engineer | Issue 187 | November/December 2020
So, what is Cross Acceptance? The concept is that a system or product, which is successfully used in one country, should be capable of being used in another country without having to go through a full back-tobasics approval process. The process is not something new and the IRSE International Technical Committee first put forward a proposal for this as long ago as 1992, focussing mainly on safety validation but stopping short of giving a formal definition of cross acceptance and how it would be implemented. Since then, the European Committee for Standardization (CEN) and the European
Committee for Electrotechnical Standardization (CENELEC) have set out some basic parameters as to how cross acceptance can be achieved. The issues can be logged as: » Specifying the functional requirements; » Compliance with international standards; » Separation of generic software from application software and between programmes and data – the system architecture; » Determination of which parts of a system are vital and how this is protected; » Whether systems can be designed to be carried out by contractors, railway engineers or both; » The need to have a validation plan. From these have emerged EU standards EN50126 (environment), EN50128 (software) and EN50129
