|
|
|
|
|
HV 11kV |
 |
|
|
|
||||||||||||
|
IT Services | ||||||||||||||
|
In keeping with our Phronesis approach (Practical Wisdom) We can not stress too highly that there are many """"solutions"""" providers out there that are prepared to provide a solution to your needs without any conception of what your problems actually consist of. Domain experience is paramount. We have some specialist engineers with many years experience of providing IT solutions to electrical networks. We are currently working with the Contracting Department of one of the largest DNO’s to provide a SCADA system to manage a very large private high voltage network. However we also have a lot of experience in providing powerful small scale IT systems to solve particular problems. We firmly believe that DATA is one of the core assets that any company can have. The value of good quality data to an organisation simply can not be overstated. Without knowing how your business works where your costs are where your customers are what your staff are doing how your assets are performing you simply do not have any ability to manage your business effectively. Many companies already know that if they understand their business they can manage it but they are also coming to understand that to know your business you have to manage a massive amount of data. Not only does data provide the basic metrics of your organisation DATA can show the relationships between apparently disconnected elements and give you insight into the way your business works. After our initial exposure to enterprise wide data issues when we were responsible within a REC for the generation of data to the Electricity Regulator we had a massive wake up call around 15 years ago when we had to collect massive amounts of data for a SCADA and asset management system. We failed to recognise the fundamental impact that data has on a project and as a result we failed to deliver on time as the data collection process and then the data manipulation process took many times longer than we had envisaged. Not only was the data a problem to collect check massage and present to users the definition of the data “objects” to the system developers was a problem. The engineers specifying the functionality of the system were simply not talking the same language as the developers trying to write the software. This was realised later into the project and we then started to communicate using data models which we could both “see” and understand. Trying to write down a data model can expose many inconsistencies in the way that you see the world and IT systems can not cope with these anomalies so a design session around a white board to come up with a common data model that suite all sides is an important and rewarding exercise. As an example we could all see that a conventional oil switch is a single object with a range of possible identities but when that oil switch is part of a “Ring main unit” its identify starts to become obscure. Is it still just a single object or is it now part of a larger RMU object. For a Scada system it is definitely a single object as it can exist in isolation on a network diagram and be operated in isolation from other switches around it but from an asset management viewpoint it does not exist, it is not the switch that will be purchased or stored or maintained; it is the RMU itself that will be delivered to site and worked on. Similarly a 132kV bulk oil circuit breaker is most definitely one object on the Scada system where it would be expected to operate all phases at once! But in the asset management system the three elements are totally separate and can be build at different times and have different modifications and be swapped out if faulty. Another simple example is that of a customer. What is a customer? Is a customer some organisation such as Tesco with many different supplies at different locations or is there individual instances of specific metered points which just happen to supply “Tesco”. Is a service cable termination a customer or is the cutout a customer. What defines a customer when there is no actual customer connected while waiting for a customer to move in. Or what is a customer when there is a looped supply, multi headed supplies or a landlords supply. Is a customer with two MPAN numbers a single customer or two customers? None of these are problems as long as there is consistency in the way that everyone discusses the issues. There needs to be a formal means of identifying exactly what people and then what systems count as a switch or a customer. The data model is a god way of formalising and publishing this agreement. Once the model is available then IT systems can be built that truly represent the way the system works. One of the major problems that DNO’s face is the reporting of no supply incidents. Each year the RIG definitions is adjusted to make companies more accountable to the customers and OFGEM. The aim being that all companies report events in the same manner and therefore can give a uniform comparable comparison fo performance and expenditure. However what the RIG actually means is different to each person with a different background. In short words are not capable of suitably describing complex relationships. OFGEM failed to agree a suitable common model that all companies could adopt and agree on. A data model is not just the way that objects relate to each other. A set of data models to the UML specification will identify fully the way the an event causes related objects to operate and the data that is passed between objects. In my time I have seen data models being produced using power point EXCEL and various flow charts but what is always missing is a set of definitions of the models that are needed and IT can in the form of the UML provide this missing rigour. There are many such anomalies to understand but if the model is constructed to take account of these then |
We are now looking for people with AP or HV network experience. Email ap@11kv.com
Call now for AP / SAP training courses | ||||||||||||||
|
info@11kv.com |
+44 (0)1444 455105 |