Guidance on oop approach to analysing power system data

Hi,

Seeking guidance on implementing an oo approach to processing power system electrical data (data is an array of instantaneous values as a function of time).

The data collected is: a) bus voltages b) node currents

Typically for a set of bus voltages there will be multiple node currents.

So for voltage planning methods to calculate RMS as function of time, frequency as function of time etc.

Similarly for current.

So this leads me (perhaps) to a voltage class and a current class... Or perhaps a bus class which has node subclasses?

For example, to calculate power in a node I need to use bus voltage and node current.

What would be a good way to organise classes for the above? Pass the bus voltage object to the node current object? Subclasses?

Appreciate guidance on the above.

Regards,

Martin.

Answer 1

[Prateek Khandelwal]

Hi Martin,

As far as Object Oriented Design is concerned, it would your real world objects ( nouns ) that are mapped to individual classes.

So, you'll have a node class, to represent nodes. And then a Bus class to represent Buses.

Now about the relationship between node and bus classes. If in your design, a node IS - A bus, then you should have node as a subclass of bus, however, if the bus HAS - A node, then you need to have node class as an attribute of the bus class.

I would like to mention this here that I have a very limited knowledge of Power Electronics, and my answer is based on my knowledge of Object Oriented Analysis and Design.

I hope this helps.

[Martin Butcher]

Hi Prateek,

Thank you for responding to the question - very helpful. The second case you describe is correct. Busses have node(s).

If you have time, I would appreciate your input on the below clarifications re the OOP implementation.

The awkwardness is different busbar instances have different numbers of nodes - so (I think) I would like to separate the basic classes for bus(voltage) and node(current).

I am thinking of structuring as follows:

1. An elec class which contains common methods, but no attributes as a top level class and "method holder".
2. A bus class (sub class of elecDomain) which contains attributes and voltage specific methods.
3. A node class (sub class of elecDomain) which contains attributes and current specific methods (for which some methods, I will need to pass in data from a bus object).
4. A busbarX class (sub class of elecDomain) which reflects the physical structure of a unique busbar instance, containing a bus class and multiple node classes.

Does this make OOP sense?