The desire to build a secure and comprehensive communications channel to the DCC is surely right. Unfortunately, the chosen design methodology has introduced a series of weak spots under the control of a series of vendors and systems. As any software professional will tell you; where complications maintaining stable and consistent communication links exist, shortcuts will be taken where possible. The result: ambiguous accountability at best; poor security and reliability at worst.
The already convoluted nature of the testing process has created a seemingly unnecessary layer of complexity to the roll-out of SMETS2. Testing reveals another complication; namely, the number of entities involved in the commissioning process. From Manufacturer to MAP, to Supplier to MOA, to Engineer to Adapter and to the DCC. Quick identification of issues is understandably difficult and assigning ownership of problems is lost in a maze to be traversed every time something untoward occurs.
What is needed is an end-to-end evaluation of the whole process – from device manufacture through to commissioning and post-installation communications – to detect where changes and improvements can and should be made. Any clarity at the moment is apportioned to each participant in the SMETS2 ‘chain’ and it would take an expert in topology to grasp the relationships and dependencies that become apparent only when installations are done in anger. (And I don’t use that phrase accidentally.)
Time for a SMETS2 End-to-end Commissioning for Dummies?
Cloud KB Limited