Hey all!
I’ve been going through the process of performing operational/system analysis and have been working on logical architecture. When doing OA/SA I keep things very solution agnostic, scoping to what the stakeholders of the system need to accomplish, and then what the system will do at a high level. As a result, there are stakeholders that I often don’t consider until I start to give the system some structure in the logical architecture.
For example…
- The stakeholders for a machine design are operators, safety personal, maintenance techs, etc. I lay out what they need to do in terms of capabilities/activities.
- I scope what the machine will be doing relative to the problem we’re trying to solve. This ends up with some machine functionality and some manual interaction from the stakeholders.
- Then, in logical architecture, I start to specify machine components that will contribute to execution of system functions.
- By starting to select certain types of logical components (spindles, robot arms, grippers, etc) I identify that I need electrical power and compressed air.
- After that I go back to my operational analysis and include the manufacturing plant power supply and compressed air supply as operational entities involved in certain capabilities, and then include functions of providing/accepting electrical power and compressed air for those entities and the system.
In general this feels right to me and fits the spirit of the tool/method, but I’m curious if others take a similar approach? Or if you potentially try to include those types of stakeholders up front based on assumptions?
Hi @DuWillia,
I do tend to agree with your post above, keep it solution agnostic. If new external actors are identified and needed during the solution definition, I would update:
- System Analysis: All the external interfaces with the system should be captured at this level. If we consider the system as a black-box, the only it can be seen are the interfaces in/out connecting the system and the external actors. Complete system ICDs can then be generated and exported. In addition, system interfaces will then allow to connect to internal components during architecture definition.
- Operational Analysis: Capturing new Entities/Actors may need some analysis to reflect the recursive work from layers below. Let’s recall that at Operational Analysis the System is not mentioned, there may be some systems that will only emerge at System Analysis, for example an actor representing a regulator. Arcadia does not impose strict rules, I think it is up to the team and project to decide what best suits to understand the System under design and define internal best practises.
I hope that helps,
Hélder Castro
2 Likes
Hi @DuWillia, I don’t think there is anything wrong with the approach you’ve defined. And as @HelderCastro has commented on, Arcadia does not impose any strict rules on you in this regard. The system architecture team should decide what is the most appropriate way of modelling.
However, my natural approach would be to keep the abstractions to the most appropriate level of the analysis. So, for example, at the SA level I’m mostly concerned about functions, functional interfaces and constraints that limit how the solution can or should work. At this point the system is purely logical – it has no mass or volume and does not require power or maintenance (after all, we don’t create products just so we can maintain them). These concerns only become valid once the LA, or even the PA, begins and the associated elements are created. At this point I am beginning to think about functions performed by mechanical, electrical or software products. It is these things that require energy and maintenance in order to perform their functions reliably, which will introduce new functions and interfaces (behavioural and physical).
In environments where mass, volume and power consumption are constrained, variant solution architectures can provide a basis for design trade-off. Thus, one LA has reduced power consumption but may require more maintenance. By modelling these concerns at the point they are brought into being it is possible to perform this trade-off.
1 Like
Sorry it took me a while to respond to this!
Thank you both @HelderCastro and @woodske for the replies. I think the idea of only introducing actors/entities where their concerns become relevant is the path we will likely take. I think it allows us to focus on the actual problem we want to solve at the OA level, and worry about constraints from other stakeholders at the SA/LA/PA levels.
Expanding on this a bit, because Helder’s example of a “regulator” got my wheels spinning some more.
In the operational analysis for a medical device, I begin by detailing the actors that will directly be performing activities related to a minimally invasive medical procedure including the physician and the patient/disease state, and some of the known systems leveraged (fluoroscopy/CT scans, guidewires, etc). Although the system is not mentioned, I’m limiting this to the actors that will actually interact with the system that I’m attempting to design, since they are performing activities related to why we’re desiging the system, to treat a disease state.
When I get to system analysis, I start to understand the boundaries of the system and what it will do, and start to introduce some constraints. This is where I think the regulatory agencies and standards come into play since they will constrain the design (material suitability, performance, etc).
I think this follows the same logic… anyone have differing opinions?
1 Like
Hi,
Stakeholder analysis and capturing at the “correct” level, may be a challenge on its own. Another example, for a stakeholder: investor. What is the most appropriate layer to capture it? I may tend to think at Operational Analysis as it may influence the System selection.
I hope it does help the thinking 
Thanks,
Hélder Castro
1 Like
Hi @DuWillia,
Your approach seems reasonable to me. As soon as you’ve decided to introduce a human-engineering system (at the SA) which will be classified as a medical device you immediately become encumbered with legislation and approvals bodies. These are external actors that introduce constraints to your solution domain and therefore you cannot ignore them. Ultimately you’ll need to reconcile this in either the LA or PA.
The question to always ask yourself is, why am I modelling this? What do I hope to clarify or learn from introducing some aspect of either the problem or solution domain. Doing so I believe will help to confirm whether you should model something at all, and if so its most appropriate introduction into the model’s structure.
Just my opinion of course 
2 Likes