Home » Polarsys » Capella General » Bottom-top operational analysis(How to capture operational entities and interactions for the [OAB] from a bottom-top analysis)
| Bottom-top operational analysis [message #1834598] |
Fri, 13 November 2020 10:33  |
 Missing name Mising name
Messages: 14
Registered: November 2020 |
Junior Member |
|
|
Hi,
I have created an example for my Capella learning purpose: [SAB] Gas power station. At this point, I am not keen if the example reflects the reality.
It does represent a gas power station and the missions are:
Mission 1: Supply energy to the grid on-demand.
Mission 2: Supply energy to electric cars.
First, I represented the gas power station (as a black-box) with the interactions/services:
- Dark-blue: users of the systems.
- Light blue: Systems needed for the gas station to accomplish the users needs.
The operating scenario could be around:
- The electric power operator requests energy to the gas power station and the gas power station generates and sends the requested electric energy to the electrical grid connector.
- A user of the electric car stops at the gas power station and recharges the car.
The remote operator can be an entity to monitor remotely the gas power station.
Second, I tried to analyse from bottom-top the [OCB] and [OAB].
The [OCB] would represent what the users of the future gas power station need to accomplish:
- Balance energy.
- Recharge car.
Third, the [OAB] I tried to capture the users and the activities needs in the diagram.
However, not sure what and how to represent the users and the different interactions.
The electrical power operator and electric car, I believe they are pretty clear they are users the future gas power station and what activities they may need.
However, when I "remove" the gas power station system entity represented at the [SAB], not sure how to represent the different interactions between the entities.
Is it correct to represent, an interaction directly from the electric power operator to the electric grid connector?
What are the interactions and entities that the electric car needs to interact with?
I don't think the remote operator should be represented at this level, as there is no system to monitor and this is not part of the missions.
Thank you.
|
|
| |
| Re: Bottom-top operational analysis [message #1834604 is a reply to message #1834600] |
Fri, 13 November 2020 12:12  |
Missing name Mising name
Messages: 14
Registered: November 2020 |
Junior Member |
|
|
Yes, a better definition for the electric car would be the user of the car and there may well be users not identified, as Google maps.
However, if we consider that this station is part of the "old" days and it is not connected to the wider world, the electric car (driver) needs to go to the gas power station and check for the status and if available purchase (recharge) energy.
We could consider the electric supply system as a user, but that would be part of the gas power station, hence, not an external entity.
Hence, the electric car/driver is not interacting with no other entity at operational level.
A fundamentalquestion for me is: Is there the need to have all users interacting at this level?
I guess, it is a good exercise to capture the interactions between users and identify their needs and activities for the next level (system).
On the other hand, is it correct to represent an interaction directly from the electric power operator to the electric grid connector within the [OAB]?
Thank you.
|
|
| |
| Re: Bottom-top operational analysis [message #1834616 is a reply to message #1834607] |
Fri, 13 November 2020 15:06 |
Missing name Mising name
Messages: 14
Registered: November 2020 |
Junior Member |
|
|
Reading again the MBSE with Arcadia:
"One of the important particularities of this perspective, which may come as a surprise, is that OA should not mention the system, so as not to bar itself from potentially interesting alternatives for achieving the satisfaction of customer needs it aims at understanding this need without any a priori assumptions about how the system will contribute thereto; this is to not restrict the scope of possibilities too quickly".
However, from all the posts above, it seems:
- there is a degree of flexibility on how the Engineer defines the operational analysis with the goal to achieve a good level of understanding without defining constraints that limits the independence of the systems definition
AND
- Achieve the stakeholder needs - input to the operational level.
Hence, for my gas power station example and at system level [SAB] - attached, there may well be a Gas supplier, external maintenance services, external regulator, etc.
This new system entities may play a role at operational analysis level IF:
- They are identified as customers/users of the future system during the operational analysis.
OR
- There are stakeholder needs defined for them.
Are the above statements correct?
|
|
|
| Re: Bottom-top operational analysis [message #1834625 is a reply to message #1834598] |
Fri, 13 November 2020 17:11 |
Jean-Luc Voirin
Messages: 8
Registered: February 2020 |
Junior Member |
|
|
Hi,
the value of any perspective, notably operational analysis, comes mainly from the questions that it raises to you, and the support for analyzing the candidate answers.
Maybe you are facing the limits of a bottom-up approach here, being possibly too much influenced by your former system need analysis.
Note: I have no competency in electrical power systems, sorry for probable mistakes.
For OA, I would start by asking 'what are the goals of the electrical power operator ?' : not to request energy to a grid connector, but rather to provide energy to customers on demand (mission or capability), ensure regulation of energy according to demand variations, etc (capabilities). For so, the operator will have activities such as product and purchase energy, monitor & control energy production, distribute energy to customers (and possibly feed grid if separate from the operator), etc.
If the grid is part of the operator, it should not be mentioned here in OA. If we consider it as a separate infrastructure, then the corresponding entity would be an external energy transport operator, or maybe the grid itself, rather than an electrical grid connector.
So the power operator activity related to the grid would rather be to provide energy, that the grid would distribute to customers (grid activity). Interaction between both would be at least the energy delivered to the grid.
Here some sources of energy are not part of the operator entity (e.g. the gas station). So you could add another entity such as Energy source (as a generic energy producer entity), and try to define what the power operator will expect from it so as to perform his activities. And you are likely to consequently make appear interactions originated in source entity, such as not only produced energy, but also energy instantaneous production level, energy delivery capacity, etc. This is necessary to feed power operator activities such as purchasing and monitoring energy, for example.
As you can see, the added value comes first of all from the continuous analysis of what is put in the model, confronting its elements.
Hope this helps.
|
|
| |
Goto Forum:
Current Time: Fri Jan 03 03:43:19 GMT 2025
Powered by FUDForum. Page generated in 0.03645 seconds |
] 
Search
Help
Register
Login
Home
