Using constraints across all system levels

Hello everyone!

I am fairly new to Capella and am struggling with using constraints on all levels of the Arcadia workflow (mostly OA at the moment). For some context, I am trying to model the requirements of the body of a bus and by exploring needs and expectations of external actors.

Unfortunately, I have made it to SA level and realized that ‘adherence to legislation/safety regulations’ is not a function but a constraint of the system. My question is how to introduce system constraints from OA level and how do I realize these constraints as I get down to SA and so on.

I have been reading up on online literature to understand the operation and capability of Capella to satisfy my modelling needs. However, I have only come across limited information on how constraints are integrated into models.

I have attached an operational capabilities model for some reference (which I am pretty sure is an incorrect application of constraints). But any assistance/feedback on the matter would be most appreciated!

Thanks, in anticipation!

Hi. From the tooling point of view, constraints in Capella can be attached to any model element. But I’m wondering if in your case the respect of legislation would be an Operational Capability, and there would be System Capabilities that would contribute to the respect of the legislation.

Hello! Thanks for your response. I am in the same predicament. As the bus body is a static structure, it can either be regulation compliant or not. The criteria that decides this is more parametric than functional. I struggle to understand which of the current capabilities would be better represented as constraints or as capabilities. Any feedback would be greatly appreciated! Thanking you, in anticipation.

In your OCB you have mapped the constraint to three operational entities. Of these I suspect the Regulatory body does not adhere to bus design regulations, they might define and enforce them maybe? The Fleet Management Company would need to ensure passenger safety, but what affect does this have upon the architectural design of the bus itself? The Bus Manufacturer will need to ensure that the product they supply is legally and functionally safe. This will usually imply the product (the bus) will need to perform in some specific way under a given set of circumstances. But it will also mandate that the manufacturer conducts the design and manufacture of the bus in some specific way, e.g. welding might need to done using specific processes – so no direct effect on the design itself.

I suspect the constraint expressed as “Adherence to bus design regulations” is too abstract to apply usefully in the OA perspective. It might be better to consider what the regulations are trying to enforce and break it down into what it actually means for the design of the body of the bus itself. For example, the OC “Protection from direct crash impact” may have a constraint that elaborates what kind of forces the bus needs to withstand and still maintain its structural integrity. This will then influence your design: structure of the chassis (monocoque vs bolted sections), crumple zones, etc. Of course, this is unlikely to reveal itself until the PA perspective.

Hello! Thank you for your message! You bring up very interesting points for me to consider, thanks! Since my initial posting of the message, I have made a few changes based on my understanding of using constraints. Now, the ‘Adherence to design regulations’ constrains only the bus manufacturer.

With respect to the influence of regulations on design, I have limited my scope only to those that directly influence the design of the bus body. One example could be the maximum width of the bus. The bus body is required to be designed to conform to this regulation. There are few but important regulations like these that influence design. I would like to touch upon at least a few for the scope of my project.

I agree with you in terms of abstraction of design regulations as I have applied here in my OA. But breaking it down would either mean a list of design regulations or dimensional constraints that are enforced on a PA level. The example you gave regarding the ‘crash protection’ capability, however, gives me a clearer view of how I can proceed with things.

Thank you for your input, it means a lot! I am tasked with the implementation of MBSE within a company for my Bachelor thesis, and MBSE is something that wasn’t even remotely touched upon in my study. Your input gives me better understanding in the approach I have chosen for my project. Please feel free to add to the feedback, comments, or any criticisms! It can only help me :slight_smile: