Software features discussion.
Icon-based technologies and object oriented approach.
During past few years at all the international conferences concerning a power plant simulation we participated, an important attention was focused on the way the simulator software system is organized. It looks like the simulator vendors from USA and Europe were able to convince customers in their countries that a good simulator firstly has to be written on C++ language in a frame of object-oriented approach and secondly it has to have an icon-based simulation technology.
We would like to share our vision of the question.
The object oriented approach was originally developed as a reply on essential requirements of the software development community. There were a number of the requirements, but we would like to mention 2 of them only:
- a facilitation of a development and utilization of so-called “reusable software components”
- a software debugging acceleration
All the requirements were successfully realized in the C++ language including.
What does the “reusable software components” mean? It means that a piece of software developed by one software programmer now without a considerable technical man-hours could be used by another software programmer. Of course it considerably facilitates a software development. And if a development engineer had developed a boiler model to be a “reusable software component” the model could be quite easily integrated to a some other simulator development project. It eases joint efforts of different simulator development companies.
A software debugging acceleration is very important for simulator vendors too, because it enabled them to much faster have a first software version and to much faster have a first contract.
So the object oriented approach has a lot of benefits from a simulator vendor point of view.
But we hope you understand that all the good things have to be paid. And the main payment here is the calculation speed of the object oriented software. The object oriented software requires a lot of a processor computational power.
After returning from 2003 SCS Western Multi-Conference in Orlando we decided to rewrite our run-time software system to the C++ language on a base of the object-oriented approach. In some time the project had been finished. And it turned out that the object-oriented executable calculates the same power unit model 10 times slowly then our usual executable written on C language.
A vendor who has just red this text could say: “No, it’s impossible. Of course there is some loss of the computational speed but the loss couldn’t be bigger then 10%. It is just a wrong C++ software design”. May be it was a wrong C++ software design but it looks like we know why we had such huge loss of the computational speed. We were to do the object’s GetValue() and SetValue() methods to be the virtual methods. But the virtual methods being a powerful essential of the object-oriented approach require a lot of processor’s instructions to organize its calling.
In the frame of our usual executable in order to add 2 values the following actions are required:
- load the 1st value to a processor register
- load the 2nd value to a other processor register
- add 2 registers
- put the result from a register to the memory
In the frame of the object-oriented executables the following actions are required:
- call the GetValue() virtual method to obtain the 1st value – to call a virtual method the C++ compiler has to organize a run-time round trip across an internal virtual function table for the object
- call the GetValue() virtual method to obtain the 2nd value
- add 2 values
- call the SetValue() virtual method to store the result to memory
Having such results we immediately stopped the project – we are not able to allow ourselves to as if return from the modern 3 GHz Pentium-4 computers back to the 300 MHz Pentium-2 ones. By using the object-oriented approaches the majority of our modern simulators wouldn’t be just able to work in real time even on 3.0 GHz dual Pentium Xeon computers.
We think that in general from a simulator customer point of view an object-oriented software doesn’t have major benefits while there is at least one disadvantage – calculation speed degradation.
Now let us discuss the icon-based technologies for model development. We don’t use it. From our point of view the technologies are the result of the 2nd generation approach to the model development. The main objective of the 2nd generation approach is to implement the known transient processes instead of an implementation of the simulated object itself. It is an essential shift of the main development objective while a power plant simulator development.
A development engineer of a 3rd generation simulator never investigates trends of variables because they say nothing to him. Of course customer’s testers do use the trends but the development engineer never uses it. What he investigates is the snap-shots of the power plant conditions simulated. The snap-shots only are able to give him a clear picture of instantaneous conditions of the power plant simulated. And we think that to analyze a snap-shot of an instantaneous power plant conditions a table-form of data representation is needed. So we use a table form of model development, analysis and investigation.
Of course theoretically speaking the icon-base tools from some USA simulator vendors we were watching at some simulation conferences could be used for snap-shot analysis too but they are not focused on the problem because the vendors do have a different simulation technology.