So I’m working my way through the Jira course and I finally came to a clear understanding of a special case I’ve been trying to clarify.
For the most part the processes of discovery and data collection result in the creation of a conceptual model. The requirements for what must be addressed (included), modified, or eliminated in the conceptual model get written up in a straightforward manner from there, and the design, implementation, and test items follow.
There was an extra step when I wrote thermo-hydraulic models for nuclear power plant simulators at Westinghouse, and that’s what I’ve been trying to classify. I think it ultimately doesn’t matter how I define it, the point of this isn’t to define a rigid, formal framework, the point is to have a flexible framework that helps you get the work done.
At Westinghouse the discovery process involved a review of drawings to identify the components of the plant that needed to be simulated to drive and be controlled by every item on the operator panels. That was performed by senior engineers in conjunction with plant personnel. The data collection process involved a trip to the plant to record all the readings and switch settings at steady state, followed by a period of researching more plant documentation to determine the dimensions and operating details of all the equipment for each system and the state of the fluids within each part of the system. This involved a lot of calculations. The requirements were for a system that generated I/O behavior for every control panel item that was within one percent of plant values at steady state and within ten percent during transients, so they were straightforward also.
So far, so good, right? Here’s where it gets trippy.
The solution involved writing first principles simulation code based on the differential equations that described the behavior of the fluid in each system. The same procedure followed for electrical models. Therefore the solution involved two steps: defining all of the required variables and governing equations, and then implementing them in code.
The issue I’ve been having when remembering all this was how to think about the write-up of the equations. In some ways it’s a conceptual representation of the plant systems, so it can be thought of as part of the conceptual model. In other ways it’s a guide for what’s required for the implementation, so it can be thought of as a specific part of the requirements. In still other ways it’s the result of a creative solution process so it’s part of the design. The architecture of the system is definitely part of the design but also part of the implementation.
I’ve been picturing the equations as part of the conceptual model, but on review they seem more properly to be part of the design, and so my confusion is potentially resolved. You may see this differently, and you’re welcome to do things your own way as your situation and impressions guide you.
Many sources (for example see here and here) inspired and informed my idea of a conceptual model, but my definition and usage applies for my framework only.
* * * * *
As an aside I can tell you that defining the governing equations and implementing them in code are very different problems. I’ve thought the hole in Westinghouse’s otherwise thorough and professional management and tracking process involved not having enough review of the methods for implementing the identified equations in code. There was a really good review process for the write-up of the equations, but there was never a review of the proposed implementation methods. The modelers were mostly left to do their best and their codes would simply be tested to see if they worked. Given the experience of some of the senior staff, including this review step might have saved a lot of wasted effort.
When I observe that I’ve seen things done well and less than well, and that my interest is always in helping organizations support things that work and avoid things that don’t, I’m often thinking of this episode. The oversight was subtle and it took me a few years to identify what was missed.