Why should all elements such as airports and airlines be included in the data format of cpacs？

[yangznufe]

Why should all elements such as airports and airlines be included in the data format of cpacs? I see that many other unified data formats, such as uml, adml, etc. do not include these external data in the data definition. I would like to know your purpose for doing this, and what are the important uses of the data from outside the aircraft in the design process?

[MarAlder]

Hi @yangznufe,

first of all, thank you for being the first user to post your question in this new Q&A forum, giving everyone the opportunity to participate in the discussion!

Your question is indeed not trivial and we often think about the best strategy, what we should map via CPACS and at which points we should better use existing standards, which partially map ohte disciplines more professionally than we could. So I like to go into a bit more detail about the current state of this topic.

Originally, CPACS comes from the conceptual design of airplanes and helicopters. Since a large part of the aviation community, which uses CPACS for its studies (e.g., DLR, Bauhaus Luftfahrt, Airbus Defense&Space, and others), has seen a focus here in recent years, the airplane/helicopter system has been mapped in increasing detail down to the component level.

Especially in more recent times, we realize that in aircraft design, we need to understand in much more detail the complex interaction of vehicles with their surrounding infrastructure, fleet structure, environmental impact, etc., and take this into account in our analyses. Design tasks in which CPACS is typically used are characterized by a variety of disciplines. Therefore, we need a standardized data exchange format that allows us to define our common language together in a very explicit way. At this point, very generic languages, such as UML or SysML, have the disadvantage that everything can be modeled individually and flexibly, but is not expressive enough for us. This leads to misunderstandings and inconsistencies in data exchange.

In our recent paper on the current status of CPACS we also compared the possibilities with ADML. Unfortunately, ADML does not provide us with a satisfactory solution to consider complex system-of-systems, since the data schema uses a bottum-up approach, which is particularly suitable for unconventional aircraft configurations. In recent years, however, the further development of ADML has been very quiet and a possible use in the modeling of system-of-systems could not yet be demonstrated.

However, as we described in more detail in our paper, our strategy with CPACS is not to map everything in the aviation domain using a single data format. On the contrary, we would like to draw on established onthologies, e.g. from the areas of production, maintenance, weather, and others in order to be able to map the entire aviation system more efficiently. At DLR, for example, intensive work is being done to link knowledge using established and new onthologies from very different domains.

However, our current studies indicate that, given the current state of development of various onthologies in the aviation sector, it is currently the most productive to include the airport and fleet structure system (including routes) in CPACS. We are currently using this in the Exact project, for example. In addition, we are looking more intensively at the area of complex system-of-systems with UAVs in the near future and we want to investigate here whether we should map this with CPACS in the future or model it via the linking of other data standards.

You see that I cannot fully answer your question, as this is the subject of current research. But you are very welcome to contribute with your ideas and, as already mentioned at the beginning, we are very happy about your comment.