| Interfaces - Capturing interface information for ICDs [message #1830648] |
Thu, 30 July 2020 13:21 |
 James Tooke
Messages: 9
Registered: January 2020 |
Junior Member |
|
|
The goal I have in mind is to use a Capella model to identify and manage my systems interfaces and eventually generate Interface Control Documents with the relevant information for sharing with our customers/suppliers. The questions I have to the community are:
"How do I best achieve this? and are there options I don't know about and should try?"
"Have others come across the same issues and have you found solutions?"
"Is there any intention for Capella/ARCADIA to improve the functionality in this area?"
For a bit of context, I work on an aerospace product that crosses many different domains (Structural, Aerodynamic, Hydraulic, Electrical, Control). The interfaces between our systems and the airframe cover all of these domains and often with a lot of detail. Generally, we generate two types of ICD (Interface Control Document). Functional ICDs and Physical ICDs.
Functional ICDs generally contain:
- the agreed characteristics about Functional Exchanges - for example:
- For electrical this could be min/max voltages and currents. Rise and fall times for data signals. Impedance etc...
- For hydraulic interfaces this could be pressures, temperatures and flow rates for the anticipated operating cycle over a typical flight(for understanding wear and component life), min/max values for component proof and burst conditions.
- For structural this could be forces/moments/displacements at different flight conditions and aircraft manoeuvres, cyclic loading and vibration characteristics.
- For aerodynamic the interface could detail the expected pressure and flow field characteristics.
- the agreed component or system behavior / timing - for example:
- the agreed output at the interface for a given input / boundary conditions
- the agreed timings (e.g. time between demand signal being provided and feedback that the demand has been achieved)
Physical ICDs generally contain:
- Component drawings of the physical geometry at the interface of joining parts
- Agreed Keep In Zones / Keep Out Zones
- Electrical Pin descriptions, Thread types, bolt patterns etc..
Everything I've said so far is scene setting, common practice and I doubt much of a surprise. The point I'm trying to get across is that while some of the information about our interfaces is nicely suited to being captured in Capella, some seems far outside Capellas scope (such as time varying descriptions of voltage/temperature/pressure, data heavy interfaces like the aerodynamic/structural or the physical information such as CAD geometry and drawings).
From what I can see the functionality for creating and describing interfaces in Capella is strongly derived from UML and seems focused on Software development. Unfortunately this isn't a great fit for my use case, which is largely a mechanical system. The Interface objects / Exchange Items / Classes / Datatypes in Capella appear highly focused towards defining data structures, the ranges of the contained data and units. While this does help me, it does not however seem to provide a means of capturing the actual values that these data structures would have in given scenarios (which is the main information I need to capture in my interfaces).
As a simple example, the information I might want to capture for a Hydraulic ICD
Scenario: Take Off on Max Hot Day
Time[s] ......|....Pressure....|.....Temperature....|.....Mass Flow
0.....................|..........30............|.............320.................|............ 20
5.....................|......... 35............|............ 340.................|............ 40
10...................|..........29............|.............325.................|.............35
Property Values are also an option for capturing information, however they only handle simple single values and not tables of data (or any other complex type). The creation of Property Values and the definition of Interfaces / Exchange Items / Data also appear semantically separate and do not mix well together, making a mixed approach to interface definition challenging.
All of this leads me to believe that Capella models seem an ideal tool to identify interfaces and agree what information should be found in an ICD document, but is not the right place to capture the actual interfaces/systems numeric details. The same seems to be true for the Physical interfaces, although Interface objects in Capella cannot be applied to Physical Links.
In which case I believe the following is needed to make this really usable:
- Ability to apply interfaces to Physical Links (for capturing Physical Interfaces)
- Ability to do bi-directional interfaces (e.g. for hydraulic / forces)
- Ability to state what Use cases / Scenarios / Failure cases will be covered in the interface definition (like "Take off" example above)
- Ability to link to the interface details held outside models (e.g. hyperlink property values?)
Do others agree with this and is this how Capella is intended to be used?
|
|
|
Powered by
FUDForum. Page generated in 0.02983 seconds
] 
Search
Help
Register
Login
Home
