Hello all!
I’m new to capella and am a bit struggling with adapting the method to my needs. In fact, I’ve followed the IFE, EOLE and Level Crossing Traffic Control examples which are all very active and/or software oriented systems.
What i’m trying to model are equipeded buildings (factories for example) which are more passive systems. Theese systems are typically decomposed into functional means (ex: machines) and non functional infrastructure (ex: walls, ventilation…). Concerning the functionnal means, i kind of got it. The building has to provide machines which fit the actors operational needs (typically in order to achive the production goal).
So my question is more about the non functional infrastructure. How can i integrate differents constraints to the model since they don’t really directly respond to the main objectives of the system? For example how can i define the need of having walls, toilets, light, etc?
Thanks in advance for any help,
David
Hello David,
interesting use case! Could you elaborate on your example in order for us to possibly suggest orientations?
- What kinds of requirements or constraints do you have for buildings, walls, ventilation etc (let’s call them ‘utilities’)?
- What kind of engineering or architecture decisions do you have to take where the model would possibly be useful?
- same question specifically regarding utilities?
- Which kinds of criteria would be used, regarding definition of utilities and their mutual influence/constraints?
- How are those expectations on utilities related to more functional features, how do they interact with each others? Do they constrain each others?
If you can give some examples, it would help.
Jean-Luc
Indeed. And maybe we should migrate this topic to the Arcadia forum ?
Thank you for your quick answer.
I’m currently working on a simplified example of a car workshop as an exercise.
The main mission is to allow the customers to have functional cars by performing maintainance, repairs, or selling new cars.
So we have actors to execute theese missions (mechanics, receptionist, comercial agent…).
As I said the SoI is the building which provides facilities to the actors. The goal is to model the needed equipements to ensure a good functionong of the workshop.
-I don’t really have specific requirements for utilities since it’s a simplified training example but we can easily imagine a need for light, acceptable temperature conditions, rain and infraction protection, toilets, cloakroom, etc…
The goal is to take everything that needs to be build into account.
-The engineering decisions are more about architecting the place itself i think since the need for the functional means is already known. This is maybe why i’m having struggles, because I think about the existing solutions of the machines while trying to execute a top down approach…
- “Which kinds of criteria would be used, regarding definition of utilities and their mutual influence/constraints?” I don’t really understand the question.
- The Utilities have to adapt to the more functional features i think. The priority is given to the functional means and the utilities have to adapt to fit good usage of functionnal means, human and product flows, reglementations, security matters, durability, etc…
I’m not sure I clearly responded to your questions since I’m not familiar with the specific vocab, so tell me if i misunderstood.
Hope this helps to understand.
David
Hello David,
I can say you that Arcadia and Capella have already been used to engineer systems that you call “passive”, such as buildings. There are several ways to do it more or less suited to your needs, so I will illustrate some of them by referring to the previous posts.
Quote:
The engineering decisions are more about architecting the place itself i think since the need for the functional means is already known. This is maybe why i’m having struggles, because I think about the existing solutions of the machines while trying to execute a top down approach…
“Passive” systems are less passive that you may think. If you think about functions as “services” that your building shall provide to the stakeholders, then you may consider functions such as “Provide light”, “Ensure tolerable temperature levels”, etc.
Arcadia & Capella are well suited for cases in which you know a solution and want to ensure that it answers all your current and/or future need, or as you say :
Quote:
The goal is to take everything that needs to be build into account
For instance, you may want to start defining a Physical Architecture of the legacy solution, then performing a System Analysis to be exhaustive about your needs, and then analyzing and defining traceability links between these engineering levels in order to make sure that the needs can be covered by the architecture.
In your case, I could imagine a Physical Architecture including several rooms of your building, rooms could be defined by Nodes. Each room may have its own lighting and heating & ventilation Behavioral Components, each one ensuring its own “Provide light” and “Ensure tolerable temperature levels” functions.
Quote:
Which kinds of criteria would be used, regarding definition of utilities and their mutual influence/constraints?
There are dependencies between these functions. For instance, if strong lighting is required, temperature of the room may increase and ventilation function may need to be executed. Moreover, these dependencies may impact you architecture: if you need a powerful ventilation subsystem for a room, you may need a larger space to allocate it; you could also get rid of a wall so that heat can go elsewhere, but in that case you wouldn’t be able to count with the services that a Wall may provide, such as Isolate, Reduce noise, Provide privacy, etc.
After consolidating the architecture you may want to think about the service you may want to provide to your stakeholders. Do you ensure that your clients are comfortable while waiting? Do you ensure that mechanics have a fast access to their tools ? Do you ensure that clients can go the bathroom at any time? You can model these services as functions of your system in System Analysis and define the Functional Chains and the Scenarios that you may want to be sure that you solution satisfy.
When you are confident that all the needs have been identified, you may want to analyze both engineering levels to check that all your needs are covered by your physical components. You will probably exclude some of the services, otherwise your car workshop will be too big or too expensive.
Quote:
For example how can i define the need of having walls
Yes, walls provide services even if they are passive (Isolate, Reduce noise, Provide privacy,…). And if you have a high-level Function or Capability that is to ensure privacy when negotiating the price of the repairing, walls may be a solution.
Hope it helps.
Thank you Juan for your very complete answer, it helped me a lot!
In fact i had thought of defining functions such as provide light ,etc but feared to lead to a very dense ans incomprehensive model…
So for now i will define very high level functions like “ensure good work conditions” and refine them in dedicaded diagrams. Hope this is the good practice.
Quote:
For instance, you may want to start defining a Physical Architecture of the legacy solution, then performing a System Analysis to be exhaustive about your needs, and then analyzing and defining traceability links between these engineering levels in order to make sure that the needs can be covered by the architecture.
Would you then forget about logical architecture (and OA)?
The thing is i’m trying to follow a top down approach because this example is only meant to be a training and possibly a guideline for future project strating from scratch.
I now have another question. How can I manage interfaces between stakeholders and system?
For example I thought about a function " be compliant with car dimensions and mass" which would ensure the correct sizing of components, openings, etc… Questions is how can I link this requirement function to ensure its realisation (by a component or so?)? I see we can add descriptions to different components which would take this requirements into account but don’t see how to link it with the capella function itself and so have a traceability/proof that the requirement is fullfilled.
Thanks again for your help,
David
Quote:
Would you then forget about logical architecture (and OA)?
Never
It will depend on your needs. For instance you may want to define a Logical Architecture that is functions-driven, meaning that you will end with Logical Components for you Ventilation & Heating subsystem, Electrical Subsystem, etc ; because youu are interested in defining the major dimensioning interfaces between these subsystems.
Then you could go for a Physical Architecture that would be topology-driven, in which you will model your rooms and how your subsystems are allocated to these rooms, and you may want to identify the detailed interfaces taking into account the stuff that is done in each room. This is only an example, again it will really depend on your needs.
Quote:
I now have another question. How can I manage interfaces between stakeholders and system?
For example I thought about a function " be compliant with car dimensions and mass" which would ensure the correct sizing of components, openings, etc… Questions is how can I link this requirement function to ensure its realisation (by a component or so?)? I see we can add descriptions to different components which would take this requirements into account but don’t see how to link it with the capella function itself and so have a traceability/proof that the requirement is fullfilled.
I’m not sure I understand well. I have doubts about considering such compliance requirement as a function. , so I my answer will be in fact two answers:
- if you consider it as a Requirement, you can create a Non Functional Requirement in Capella and then use the “Requirement Manager” Wizard to link any element (so for instance a Component) to this Requirement and ensure traceability.
- if you consider it as a Function (again, I don’t think that this is the case), Functions are allocated in Components, meaning that Components are in charge of performing this function. When you allocate you create traceability between Functions and Components.
Hope it helps
Defining a function-driven LA and a topology driven PA is actually what i did in the meantime and it seems to be apropriate for my needs.
Quote:
I’m not sure I understand well. I have doubts about considering such compliance requirement as a function. , so I my answer will be in fact two answers:
- if you consider it as a Requirement, you can create a Non Functional Requirement in Capella and then use the “Requirement Manager” Wizard to link any element (so for instance a Component) to this Requirement and ensure traceability.
- if you consider it as a Function (again, I don’t think that this is the case), Functions are allocated in Components, meaning that Components are in charge of performing this function. When you allocate you create traceability between Functions and Components.
For now i have identified three different possibilities:
- first possibility is to consider it as a requirement and create a non functional requirement as you said. I would then create high level requirements packages at SA. Then i would create constraints on my components at PA and link theese constraints to the previously defined requirements. Advantage is that each PC contains a clearly identified constraint that corresponds to the high level requirement. Drawback is that the requirements are not very visible in the model before PA…
- second possibility was to define high level requirement functions in SA such as “comply with legislation” or “withstand environmental conditions” which will then be split into subfunctions to fit the different components. Advantage is that the requirement is visible very early in the model. Drawback is it will considerably complexify the model + i’m not sure i want to have requirement functions allocated to components in LA/PA.
- third option would be to create interfaces between the system and actors like “environment”, “vehicle”, “authorities”. Problem is i don’t really know for now how interfaces work and if we can use them for such purposes. They might be apropriate for adaptation purposes like the good fit between the size of a door and the size of a vehicle, or the adequation between the air conditioning power and the average local temperatures, but maybe they are not apropriate for legislation constraints. As i said i don’t really know how they work and found view material to enhance my knowledge on it.
I would very appreciate your feedback on theese options.
David
My own view would probably be a merge of your first and last possibilities.
Pure requirements should not be expressed as functions (or operational activities): a function is a service to be delivered, which means that it has some expected outputs and may expect some inputs so as to fulfill the service, which leads to connecting the function to others by functional exchanges expressing dependencies. “comply with legislation” or “withstand environmental conditions” are therefore not functions, but rather requirements.
That said, requirements or constraints are definitely part of your need ‘model’, even if not yet linked to functions or components or interfaces. They are just different and complementary means to express need.
Now, let’s consider each requirement:
“comply with legislation” is too vague to have any influence on architecture definition, so keep it as requirements or refine and detail it; then if you consider safety legislation, you will have feared events (OA, SA) and critical functional chains (SA, LA PA), redundant components (in LA PA) etc. to which you will be able to link the safety requirements, and possibly reliability constraints for example. But here, an external actor such as “authorities” will bring no value.
“withstand environmental conditions” is also to be refined : if it is a matter of environment temperature range, then keep it as a requirement until you have defined physical assets to which you will allocate them, depending on their location for example. If it is a matter of heavy rain, then you will have possibly (at system or subsystem level) functions and components in charge of evacuating rain water, to which you will allocate these requirements. Etc.
" be compliant with car dimensions and mass" is more interesting, because it can interact with real functions early:
in OA, you should describe the kinds of vehicles your garage will have to take over, via operational entities (by the way, you should keep an OA !), to describe the kinds of expectations for each of them (e.g. repair in case of failure, ensure maintenance…). Then you can allocate some requirements to them, or constraints, or properties, to define other characteristics such as size, weight etc.
In SA, you will define what kinds of services the garage should deliver to these vehicles (detailing a bit the former operational activities and pointing out which part the garage is in charge of) as system-allocated functions, including garage specific ones such as ‘receiving clients’, ‘filling commercial documents’ and more.
IN LA and especially in PA, you will probably have a place (component) in the garage (‘reception hall’), dedicated to taking over the vehicle; it will implement functions such as ‘fill in the agreement’, ‘store vehicle temporarily’…, each being related to a function on the vehicle owner actor side (‘enter the garage’) by a functional exchange.
You might allocate maximum weight requirements or constraints to these functions and components; regarding size you might define a physical link and physical port to represent the entry door frame, to which you would allocate the “size interface” constraint. On the owner actor side, the port would express the outline of the vehicle.
Note that the maximum size should come from the OA which characterized the different kinds of vehicles (you should keep an OA !
).
A very simplified view would look like this:
Thank you Jean-Luc for your very detailled answer!
I now have a good idea of how i can manage the requirements and constraints. Don’t worry I wasn’t going to let OA down, but I think I will have to re-detail it a bit
.
Concerning requirements, should I define packages in OA or rather in SA? I don’t see any transition tool for requirements and constraints… Does it mean I have to redefine requirements at each layer and link them to the upper layer requirements?
You didn’t tell me about interfaces (I mean CDI and CEI diagrams). What for are they meant to be? And how are they supposed to be used? (could they partly fulfill my needs?)
Thanks again!
Regarding requirements, you can create them in any perspective, from OA up to PA (or even BS), and then link them to any model element of any perspective, so no need to duplicate them: for example,
your user or system requirements would be mainly created in SA, as part of the system need description;
they can be linked to SA functions, functional chains and so, but also directly to logical or physical elements (e.g. to a sub-system component which is the only one to be concerned by the requirement).
you can define sub-systems requirements up to PA, and allocate them to those PA elements which describe these sub-systems; these are often used to describe non functional constraints, or to detail what is expected from each PA function, for example.
Interfaces are intended to describe the data part of the contract between two components (or a component and an external actor). In the data model, you can describe what is expected to be exchanged between them (information, data, signals, images, material, mechanical force or torque, fluid…), and then you can define how it is exchanged by means of exchange items (e.g. a command, an event, a fluid with several physical properties…), carried by exchanges. Interfaces allow to group these exchange items into semantically consistent ways of interacting with a behavioural component through its ports.
Please refer to Arcadia and Capella documentation for this. In the scope of the current discussion, I think you should not care about interfaces for the moment.
Thank you for all the explanations
Hello and thank you for this discussion! The part where ‘compliance to regulation’ shouldn’t be expressed as a function but a requirement or constraint was very helpful. Unfortunately, I have already made my models around this error. To correct this, would you suggest switching the operational capability of ‘regulation adherence’ with a constraint and connecting them to actors and entities in OA?
For some context, I am trying to use Capella for a modelling exercise to determine the requirements of a bus. I have attached a capability diagram which models ‘regulation adherence’. I am fairly new to following the ARCADIA methodology and using Capella. I have however read through manuals and online literature to find my way in using the software to my need.
Any input on the integration of constraints in my models would be most helpful! Thanks in advance!
