EP2476072A1 - Konfigurationsgesteuerte dynamische erzeugung von produktdaten für komplexe produkte - Google Patents

Konfigurationsgesteuerte dynamische erzeugung von produktdaten für komplexe produkte

Info

Publication number
EP2476072A1
EP2476072A1 EP10749658A EP10749658A EP2476072A1 EP 2476072 A1 EP2476072 A1 EP 2476072A1 EP 10749658 A EP10749658 A EP 10749658A EP 10749658 A EP10749658 A EP 10749658A EP 2476072 A1 EP2476072 A1 EP 2476072A1
Authority
EP
European Patent Office
Prior art keywords
module
level
sub
plans
validated
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP10749658A
Other languages
English (en)
French (fr)
Inventor
Tobias SCHMIDT-SCHÄFFER
Ulrich Seifert
Ulf Schiller
Benjamin Becker
Milton Amador
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Operations GmbH
Original Assignee
Airbus Operations GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Airbus Operations GmbH filed Critical Airbus Operations GmbH
Publication of EP2476072A1 publication Critical patent/EP2476072A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/15—Vehicle, aircraft or watercraft design
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2111/00—Details relating to CAD techniques
    • G06F2111/04—Constraint-based CAD
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2111/00—Details relating to CAD techniques
    • G06F2111/20—Configuration CAD, e.g. designing by assembling or positioning modules selected from libraries of predesigned modules
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2113/00—Details relating to the application field
    • G06F2113/28—Fuselage, exterior or interior
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation

Definitions

  • the invention relates to a method and a device for computer-aided construction of building plans for modular aircraft components.
  • a passenger plane consists of a large number of components. Many of these components can and are ordered by the respective airlines in a particular form, modification or configuration, i. E. They are made on customer request.
  • Construction documents such as building plans and other documentation, are then created on the basis of this specification material.
  • Construction documents such as building plans and other documentation, are then created on the basis of this specification material.
  • the immense combination possibilities make this pre-engineering step time-consuming and expensive. There is therefore a need in the aircraft industry, the
  • the present invention addresses this need in the aerospace industry by providing a method and apparatus for automated or computer-aided building of blueprints for modular aircraft components.
  • the method is based on already validated substructure plans for the individual
  • Modules wherein the respective modules elements are assigned.
  • This module / element structure defines a hierarchy that includes at least two levels: a module level and an element level.
  • the method then includes the following steps: Responsive or "user” input is re-specified or modified at the elemental level of at least one of the elements in one of the module (sub) blueprints, thus at least one individualized module sub-plan so that several options can be offered. These then restrict the module parameters that may be affected at all - in a sense, the solution space as well.
  • Module subplans of the validated combination so as to obtain a validated blueprint or to simplify its validation.
  • the partial construction plans or the validated final construction plan are preferably in
  • the aircraft component may be, for example, a cabin of a
  • Seating units in turn are made up of elements such as rows of seats. Each row of seats includes a specified number of seats.
  • the elements may also correspond to toilet or kitchen cabins, seats for passenger attendants, emergency equipment or other configurable
  • one or more of the individual elements within the already validated substructure plans are linked either to one another or to elements in other already validated substructure plans. This link may also apply to module features at the module level
  • Partial module plans extend. By modifying the element, a dynamic-automatic (co-) modification of the other elements or module features associated with this element then takes place. The settlement of this
  • Linkage or links are based on rules and are also based on constructional considerations necessary or on specifications of the national aviation federal offices.
  • the method allows a faster production of construction documents for the final assembly of the ordered passenger aircraft.
  • the invention also provides a corresponding apparatus for computer-aided design of the blueprint for modular aircraft components. Furthermore, the invention provides a program element or an electronic data carrier for the computer-based feasibility of the method.
  • the method according to the invention and the device according to the invention thus permit a configuration-controlled, dynamic generation of product data or construction documents for customer-configured aircraft components, based on a modular product structure.
  • Validation / validation A sub-plan is valid ("validated") if the aircraft component specified therein meets design requirements and the specifications ("rules") of the Federal Aviation authorities. The process of checking whether the sub-plan meets these requirements and the rules is called “validate.” If so, the validation succeeds, if not, a warning message is issued to the user, eg in the form of a pop-up Windows on a screen or the configuration is not allowed over the program, and the customer led to a similar buildable solution. The user should then revise an entry so that a new validation can be started.
  • Levels / Hierarchies On databases, the already validated partial module construction plans are stored as electronic data structures, whereby the data structures are suitable for mapping the two or more levels of the hierarchy.
  • the higher module level refers only to specifications or (module) features, ie technical parameters that affect the module itself as an independent component.
  • the module characteristics thus determine the "global" properties of the module, which also includes relationships between the elements of the module.
  • “Local” properties of the element itself can be modified or specified at the lower element level, for example: Where exactly one seat is located in a module Seating Group Unit is a global property determined by the corresponding module feature, whereas the color of the seat cover is one Local property of the item "seat", which is determined by the corresponding
  • Element characteristic is determined. Modification on the (deeper) element level means changing a feature element. Modification at the (higher) element level means changing a module feature. A modified element or module is considered individualized. It should be noted that
  • Blueprint includes product data as well as other documentation required for the final assembly of the customized aircraft or
  • Data Structures Nestable or tree-like data structures are well suited for mapping this level hierarchy. The deeper a level, the deeper the corresponding descriptive data (element or module feature) is nested.
  • other data structures such as e.g. the associative arrays known from the Perl programming language, i. Fields via "Key / V alue" pairs
  • relational databases can also be used.
  • Fig. 1 shows a schematic block diagram of a production or
  • Fig. 2 shows a modular aircraft cabin.
  • FIG. 3 shows a seat row element from one of the seat group modules in FIG.
  • FIG. 4 shows a schematic flowchart of the method for
  • FIG. 1 shows a schematic block diagram of a device VEB for automatically generating blueprints for modular aircraft components.
  • a module is z.
  • B. a set of passenger seat groups within a zone in one
  • Passenger aircraft cabin A module consists of several elements, e.g. the individual rows of seats. Other examples of cabin zone elements would be kitchen or toilet cubicles.
  • the device VEB comprises a computer PD which is controlled by an engineer or customer ("user") via a user interface UI
  • User interface UI can here be a graphical user interface (GUI), in which the control takes place via a known menu structure.
  • GUI graphical user interface
  • the user enters his desired selection via the user interface UI.
  • the options for the element are automatically set by the system and the dimensioning / positioning is invariant specified by the module.
  • Passenger cabs use would be, for example, the user required water pressure for the pipe or the specification of electrical Cabling with regard to the electrical power of kitchen appliances in the kitchen cabins. However, it is not these parameters that are usually configured, but the options of the element - and the "parameters" are then derived from the configuration. The rules ensure accordingly that these parameters are in a valid range (buildability, ).
  • a number of already validated substructure plans, from which the later construction plan SPEC is combined, are available on a database system DB.
  • Subplans specify the respective modules through module features on a higher module level.
  • the parameters are, for example, filled in a scheme (template), which is thereby completed to the finished and valid construction document.
  • template a scheme
  • some automated information is added as well: user specifies options, date and airline come from other databases, together it is a construction document for a specific MSN.
  • element features specify the elements that are arranged in the modules. This defines a two-level hierarchy.
  • the substructure plans as well as the building plan SPEC to be created can be realized, for example, as structured XML files or
  • this hierarchy which covers at least two levels, can be mapped by nesting well-known XML tags ⁇ ,>.
  • a validation unit VAL is communicatively connected to the computer PD and a rule database DBV.
  • the rule database DBV for example, rules prescribed by the Federal Aviation authorities are stored in table-like data structures.
  • the table-like data structure includes at least two columns.
  • identifiers for the respective modifiable elements of the subplans.
  • associated line in the second column is the respective specification values, for example as a code, numerical values or as
  • a color may be coded for a seat cover of a seat.
  • one or more of the individual elements within the already validated substructure plans are linked either with each other or with elements in other already validated substructure plans.
  • Linkage may be to module features in moduleben of the partial module layouts extend.
  • a dynamic automatic (co-) modification of the other elements or module features associated with this element then takes place.
  • the setting of this link or links is designed rule-based and are also based on constructional considerations necessary or on specifications of the national aviation federal agencies.
  • the sub-plans are then combined by the computer PD.
  • Combining can be done, for example, by merging the individual XML files into an overall XML file, or else by linking the sub-plans to be combined via links ("links").
  • the validation unit VAL can be designed, for example, as a "parser", which passes through the respective entries in the substructure plans and there
  • the final building plan SPEC can be given to a computer-aided design system (CAD) to create a graphical master plan, which can then be used to create a final master plan SPEC For example, be checked by an engineer.
  • CAD computer-aided design system
  • Control device or interface CON are fed, so that via this control device CON a manufacturing plant MANU can be loaded with those components that have been specified in the finished plan SEPC.
  • z. B. industrial supply robot can be controlled, or
  • Low-floor vehicles in warehouses in order to provide the components or components specified in the final construction plan SPEC with the respective dimensions or characteristics or to deliver them to a predetermined destination for final assembly.
  • Fig. 2 and Fig. 3 the modules and elements or their specification are referred to as module sub-plans with the same reference numerals for simplicity of illustration.
  • Fig. 2 shows an overview of a modular aircraft component.
  • the aircraft component is an aircraft cabin FC.
  • FC has a floor plan that consists of different zones A - E.
  • the zones differ in that there are doors in zones A, C, E and none in zones B, D.
  • Different seating group modules MB, MD are attributable to the respective Seagzonen B, D.
  • additional modules supply areas MC are available, such as toilet cubicles or kitchen cabins.
  • the special seating group modules MA, ME are for the cockpit and for the rear of the aircraft E
  • Each seat group module MA, MB, MD and ME are thereby cabin elements, such as individual rows of seats E, assignable, as shown in Fig. 3.
  • each cabin element "seat row S" can be modified, that is to say specified by a certain expression, for example the expression "with monitor” would lead to a modified seat row SK in which the backrests are equipped with monitors.
  • FIG. 3 for the sake of clarity, only a pictorial representation of the substructure plan of the seat group module MB with the associated cabin element S is shown by way of example. For the others
  • Cabin modules MA, MC - ME are analogous.
  • the validation does not take place down to the element level.
  • the pre-validation is chosen so that the choice of a certain characteristic for a particular cabin element in a seat group module to regulate, in accordance with DBV requires no new validation.
  • the seat row E in Fig. 3 is regularly mounted in the module MB to valid and the comprehensive module MB is valid, even if the cabin element E has been fitted / modified in the cabin element EKA with monitor.
  • An XML coding of the module sub-plan MB can look like this:
  • Module feature MB_l mb_l, ...>
  • the validation device VEB is adjustable or programmable up to which level depth the validation should take place.
  • the validation takes place only at the module level.
  • it is also a validation strategy with a finer granularity conceivable by, for example, the cabin elements E are composed of sub-elements corresponding to the individual seats. In that case you would have three levels.
  • the device VEB is then set up so that it can be set whether it is to be validated only on the first / highest (module level), or also on the second (element level) or also on the third level (sub-element level).
  • the device VEB allows greater flexibility, which, however, would then also have been paid for by a more intensive computing time of the validation unit VAL.
  • the device VEB can be optimally adapted to the needs of computing capacity and required flexibility.
  • the validation unit VAL, the computer PD and the database systems DB, DBV or the user interface UI can each act as their own hardware or
  • the implementation is done on a single local computer.
  • a client-server structure is provided for a web-based embodiment of the validation device VEB.
  • the provision of the technical specification data about the customer is made by a client presenting the UI UI.
  • a data exchange with the computer PD (“server") then takes place via a network connection, such as the Internet, for example.PD is in turn connected via the network to the database systems DBV or DB If the completed construction plan SPEC has been validated and combined, then These are then sent via the network connection to the control unit CON to coordinate the further final assembly in the factory MANU.
  • Fig. 4 shows for clarity a flow chart of the method
  • Device VEB for computer-aided creation of the building plan SPEC is based.
  • a first step S5 an optional element-level modification takes place. At least one of the elements E becomes a modified element EKA so that you get so an individualized, so specially adapted to the needs of the user sitting group module, resulting from the already pre-validated module MB. The same applies to the other modules MA, MC-ME.
  • step S10 a validation is carried out that is adjustable only at the module level.
  • the combination of one or more of the modules MA, MC-ME is validated with the individualized module.
  • An optional step S15 is based on a combination of the individual elements S within the same module or else with other elements in other modules MA, C-E. If a modification of the element S has taken place in the previous step S10, a corresponding modification of the linked elements based on rules also takes place automatically, either in the same or in the respective other modules MA, C-ME. These rules are also based on the rules of the rules database DBV. This dynamic co-modifying may, for example, be logically necessary or constructional. Due to this dynamic co-modification, user input is no longer required at this point in the workflow. Otherwise, the user would have to "move in manually" each time and adjust the feature in the other subplans
  • the validated partial module layouts are assembled in step S20 so as to obtain a validated final module plan SPEC.
  • the database DB can then be updated by storing the validated construction plan SPEC, together with an ID of the customer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Geometry (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Optimization (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Ein Verfahren und eine Vorrichtung zum computergestützten Erstellen eines Bauplans für modulare Flugzeugbauteile auf Grundlage von validierten Teilbauplänen für einzelne Module.

Description

Konfigurationsgesteuerte dynamische Erzeugung von Produktdaten für komplexe
Produkte
VERWANDTE ANMELDUNGEN
Die vorliegende Anmeldung beansprucht die Priorität der US Provisional
Patentanmeldung Nr. 61/240,776, eingereicht am 9. September 2009, und der deutschen Patentanmeldung Nr. 10 2009 040 731.6, eingereicht am
9. September 2009, deren Inhalte hierin durch Referenz inkorporiert werden.
TECHNISCHES GEBIET DER ERFINDUNG Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum computergestützten Erstellen eines Bauplans bzw. Bauunterlagen für modulare Flugzeugbauteile.
TECHNISCHER HINTERGRUND
Die von Flugzeugherstellern an Fluggesellschaften ausgelieferten Passagierflugzeuge sind komplexe technische Systeme.
Ein Passagierflugzeug besteht aus einer großen Zahl von Komponenten. Viele dieser Komponenten können und werden von den jeweiligen Fluggesellschaften in einer bestimmten Ausprägung, Modifikation oder Konfiguration bestellt, d.h. sie erfolgen auf Kundenwunsch.
Jede Fluggesellschaft hat neben bestimmten Wünschen hinsichtlich der
Innenausstattung des Flugzeuges Vorgaben, die von den jeweiligen nationalen Luftfahrtbehörden vorgeschrieben werden. Die Bereitstellung der jeweilig unterschiedlich konfigurierten Komponenten zur Endmontage erfolgt im Rahmen eines sogenannten„Realisation-Engineering". Dabei werden die unterschiedlichen Konfigurationen oder Spezifikationen, die von der Fluggesellschaft gefordert werden, erfasst.
Auf Grundlage dieses erfassten Spezifikationsmaterials werden dann Bauunterlagen, wie zum Beispiel Baupläne und sonstige Dokumentation erstellt. Durch die immensen Kombinationsmöglichkeiten ist dieser Pre-Engineering- Schritt zeitraubend und teuer. Es besteht also ein Bedarf in der Flugzeugindustrie, die
Entwicklung durch das gezielte modulorientierte Pre-Engineering von geeigneten Baugruppen für das Flugzeug effizienter zu gestalten.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung adressiert diesen Bedarf in der Luftfahrtindustrie durch Bereitstellung eines Verfahrens und einer Vorrichtung zum automatisierten bzw. computergestützten Erstellen von Bauplänen für modulare Flugzeugbauteile.
Das Verfahren basiert auf bereits validierten Teilbauplänen für die einzelnen
Module, wobei den jeweiligen Modulen Elemente zugeordnet sind. Durch diese Modul/Element- Struktur ist eine Hierarchie definiert, die mindestens zwei Ebenen umfasst: eine Modul- und eine Elementebene. Das Verfahren umfasst dann die folgenden Schritte: Responsiv bzw. als Reaktion auf einen Benutzer („User")-Input wird auf Elementebene mindestens eines der Elemente in einem der Modul (Teil-) Baupläne re-spezifiziert bzw. modifiziert, um so mindestens einen individualisierten Modulteilbauplan zu erhalten. Es können also mehrere Optionen angeboten werden. Diese beschränken im Weiteren dann die Modulparameter die überhaupt betroffen sein können - also in gewisser Weise auch den Lösungsraum.
Danach erfolgt ausschließlich auf Modulebene ein Validieren der Kombination eines oder mehrerer der Modulteilbaupläne mit dem so individualisierten Modul. Bei erfolgreicher Validierung erfolgt dann eine Zusammensetzung der
Modulteilbaupläne der so validierten Kombination, um so einen validierten Bauplan zu erhalten, bzw. dessen Validierung zu vereinfachen.
Validiert heißt hier insbesondere, dass die jeweilige Modifikation bzw. der zusammengesetzte Bauplan („die Kombination") in seiner Gänze den von den Luftfahrtbundesämtern vorgeschriebenen Regeln und darüber hinaus auch technischen Anforderungen (Konstruktion und Fertigung) des Herstellers genügt.
Die Teilbaupläne bzw. der validierte Endbauplan liegen vorzugsweise in
elektronischer Form zum Beispiel als strukturiertes XML-Dokument vor.
Beim Flugzeugbauteil kann es sich zum Beispiel um eine Kabine eines
Passagierflugzeugs handeln. Den einzelnen Modulen entsprechen z. B.
Sitzgruppeneinheiten in bestimmten Zonen eines Passagierflugzeugs. Die
Sitzgruppeneinheiten wiederum sind aus Elementen wie zum Beispiel Sitzreihen aufgebaut. Jede Sitzreihe umfasst dabei eine spezifizierte Anzahl von Sitzen. Die Elemente können aber auch Toiletten- oder Küchenkabinen entsprechen, Sitzen für Passagierbegleiter, Notfallausrüstung oder sonstige konfigurierbaren
Kabineneinbauten. Gemäß einem weiteren Aspekt der Erfindung sind ein oder mehrere der einzelnen Elemente innerhalb der bereits validierten Teilbaupläne entweder untereinander oder mit Elementen in anderen bereits validierten Teilbauplänen verknüpft. Diese Verknüpfung kann sich auch auf Modulmerkmale auf Modulebene der
Modulteilbaupläne erstrecken. Durch Modifikation des Elements erfolgt dann auch eine dynamisch-automatische (Mit-)modifikation der mit diesem Element verknüpften anderen Elemente bzw. Modulmerkmale. Die Setzung dieser
Verknüpfung bzw. Links ist dabei regelbasiert ausgebildet und beruhen ebenfalls auf konstruktionstechnisch notwendigen Überlegungen bzw. auf Vorgaben der nationalen Luftfahrtbundesämter.
Zum Beispiel hat das Setzen einer Toilettenkabine an eine bestimmte Position innerhalb des Moduls zur Folge, dass an dieser Stelle kein Fenster nötig ist. Die Verlinkung würde also bei dieser Modifikation„Setzen einer Kabine an die Position X" zur Folge haben, dass auf Modulebene das Modulmerkmal in dem jeweiligen Modulteilbauplan an der Position X nicht gesetzt wird.
Insgesamt erlaubt das Verfahren eine schnellere Erzeugung von Bauunterlagen für die Endmontage des bestellten Passagierflugzeugs.
Der Konfigurationsprozess und damit die Auslieferung des Flugzeuges wird bei gleichbleibenden oder niedrigeren Kosten beschleunigt.„Ad hoc" Ausführungen von konstruktiven Änderungen in dem auszuliefernden Passagierflugzeug können so vermieden werden. Außerdem kann durch die (Wieder-) Verwendung bereits validierter Module ein Validierungsschritt schneller erfolgen, da nicht bis zur Elementebene„herunter- validiert" werden muss.
Dadurch wird der Rechenaufwand erheblich herabgesetzt und eine computergestützte Implementierung des Verfahrens zum Beispiel in einem webbasierten System mit Client-Server Architektur kann so mit akzeptablen Reaktionszeiten realisiert werden.
Die Erfindung stellt auch eine entsprechende Vorrichtung zum computergestützten Erstellen des Bauplans für modulare Flugzeugbauteile bereit. Des Weiteren stellt die Erfindung ein Programmelement bzw. einen elektronischen Datenträger zur computerbasierten Ausführbarkeit des Verfahrens bereit.
Das erfindungsgemäße Verfahren und die erfindungsgemäße Vorrichtung erlauben somit eine konfigurationsgesteuerte, dynamische Erzeugung von Produktdaten bzw. Bauunterlagen für kundenspezifisch konfigurierte Flugzeugbauteile, basierend auf einer modularen Produktstruktur.
Definitionen
Validierung /Validiert: Ein Teilbauplan ist valide („validiert"), wenn das darin spezifizierte Flugzeugbauteil konstruktionstechnischen Erfordernissen und den Vorgaben („Regeln") der Luftfahrtbundesämter genügt. Der Vorgang des Prüfens, ob der Teilbauplan diesen Erfordernissen und den Regeln genügt heißt„Validieren". Wenn dem so ist, dann ist die Validierung erfolgreich. Wenn nicht, so wird eine Warnmeldung an den Benutzer abgesetzt, z.B. in Form eines Pop-up Windows auf einem Bildschirm oder die Konfiguration wird über das Programm nicht erlaubt, und der Kunde zu einer ähnlichen baubaren Lösung geführt. Der Benutzer sollte dann eine Eingabe revidieren damit eine neue Validierung gestartet werden kann.
Möglich ist hier aber auch, dass invalide Auswahlmöglichkeiten/Optionen a priori ausgeschlossen werden ("ausgrauen") und ggf. bei dem Versuch der Auswahl eine detailliertere Begründung hinsichtlich der Regelverletzung gegeben wird. So kann der Anwender/User nachvollziehen, worin die Problematik besteht und
möglicherweise an einer anderen Stelle das Produkt so abändern, dass die Option wieder ermöglicht wird.
Ebenen/Hierarchien: Auf Datenbanken sind die bereits validierten Modulteilbaupläne als elektronische Datenstrukturen hinterlegt, wobei die Datenstrukturen geeignet sind die zwei oder mehrere Ebenen umfassende Hierarchie abzubilden. Die höhere Modulebene bezieht sich nur auf Spezifikationen bzw. (Modul-)Merkmale, also technischer Parameter, die das Modul selbst als eigenständiges Bauteil betreffen. Die Modulmerkmale bestimmen also„globale" Eigenschaften des Moduls. Hierunter fallen auch Beziehungen zwischen den Elementen des Moduls.
„Lokale" Eigenschaften des Elemente selbst, werden dagegen auf der niedrigeren Elementebene modifizier oder spezifizierbar. Beispiel: Wo genau ein Sitz in einem Modul Sitzgruppeneinheit steht, ist eine globale Eigenschaft, die durch das entsprechende Modulmerkmal bestimmt wird. Die Farbe des Sitzbezuges ist dagegen eine lokale Eigenschaft des Elements„Sitz", die durch das entsprechende
Elementmerkmal bestimmt wird. Eine Modifikation auf der (tieferen) Elementebene bedeutet ein Ändern eines Elementmerkmals. Eine Modifikation auf der (höheren) Elementebene bedeutet eine Ändern eines Modulmerkmals. Ein modifiziertes Element oder Modul gilt als individualisiert. Es ist zu beachten, dass
Regeländerungen auf der lokalen "Element"-Ebene sich nicht auf die Modulebene auswirken, falls dies unerwünscht ist. Bauplan: umfasst Produktdaten und auch andere Dokumentationen, die für die Endmontage des gemäß Kundenwunsch individualisierten Flugzeugs bzw.
Flugzeugbauteil Verwendung finden. Datenstrukturen: Schachtelbare oder Baumartige Datenstrukturen eignen sich gut zum Abbilden dieser Ebenen-Hierarchie. Je tiefer eine Ebene ist, desto tiefer sind die entsprechenden beschreibenden Daten (Element- oder Modulmerkmal) geschachtelt. Neben XML-Dateien eignen sich auch andere Datenstrukturen wie die z.B. die aus der Programmiersprache„Perl" bekannten assoziativen Felder („associative arrays"), d.h. Felder über„Key/V alue" Paare. Neben XML Daten können auch relationale Datenbanken eingesetzt werden.
KURZE BESCHREIBUNG DER FIGUREN
Fig. 1 zeigt ein schematisches Blockdiagramm einer Produktions- bzw.
Fertigungsanlage mit einer Vorrichtung zum computerbasierten Erstellen von Bauplänen gemäß einer Ausführungsform der
Erfindung.
Fig. 2 zeigt eine modular aufgebaute Flugzeugkabine.
Fig. 3 zeigt ein Sitzreihenelement aus einem der Sitzgruppenmodule in Fig.
2.
Fig. 4 zeigt ein schematisches Flussdiagramm des Verfahrens zum
automatischen Erstellen des Bauplans für modulare Flugzeugbauteile gemäß einer Ausführungsform der Erfindung. Die Figuren sind nicht skalengetreu und stellen lediglich eine exemplarische Ausgestaltung der Erfindung dar. Gleiche Bezugszeichen in den Figuren bezeichnen gleiche Merkmale.
DETAILLIERTE BESCHREIBUNG VON AUSFÜHRUNGSBEISPIELEN
Fig. 1 zeigt ein schematisches Blockdiagramm einer Vorrichtung VEB zum automatischen Erstellen von Bauplänen für modulare Flugzeugbauteile. Ein Modul ist z. B. eine Menge von Passagiersitzgruppen innerhalb einer Zone in einer
Passagierflugzeugkabine. Ein Modul besteht aus mehreren Elementen, z.B. den einzelnen Sitzreihen. Andere Beispiele für Elemente der Kabinenzonen wären Küchen- oder Toilettenkabinen.
Die Vorrichtung VEB umfasst einen Rechner PD, der von einem Ingenieur oder Kunde („User") über eine Benutzerschnittstelle UI gesteuert wird. Die
Benutzerschnittstelle UI kann hier eine graphische Benutzeroberfläche (GUI) sein, in der die Steuerung über eine an sich bekannte Menüstruktur erfolgt.
Über die Benutzerschnittstelle UI gibt der User seine gewünschte Auswahl ein. Es werden die Optionen für das Element vom System automatisch gestellt und die Bemaßung/Positionierung ist invariant durch das Modul vorgegeben.
Technische Parameter für Küchen- oder Toilettenkabinen, wie sie in
Passagierkabinen Verwendung finden, wären zum Beispiel der vom User erforderliche Wasserdruck für die Berohrung bzw. die Spezifikation von elektrischen Verkabelungen im Hinblick auf die elektrische Leistung von Küchengeräten in den Küchenkabinen. Konfiguriert werden in der Regel allerdings nicht diese Parameter sondern die Optionen des Elements - und die "Parameter" leiten sich dann aus der Konfiguration ab. Die Regeln gewährleisten entsprechend, dass diese Parameter sich in einem validen Bereich befinden (Baubarkeit, ...) .
Eine Menge von bereits validierten Teilbauplänen, aus denen der spätere Bauplan SPEC kombiniert wird, liegen auf einem Datenbanksystem DB bereit. Die
Teilbaupläne spezifizieren durch Modulmerkmale auf einer höheren Modulebene die jeweiligen Module.
Die Parameter werden beispielsweise in ein Schema eingefüllt (Template), welches dadurch zu der fertigen und gültigen Bauunterlage komplettiert wird. Beispielsweise kommen auch ein paar automatisierte Informationen hinzu: Anwender spezifiziert Optionen, Datum und Fluglinie kommen aus anderen Datenbanken, gemeinsam ist es eine Bauunterlage für eine Bestimmte MSN.
Auf einer tieferen Elementeben sind durch Elementmerkmale die Elemente spezifiziert, die in den Modulen angeordnet sind. Dadurch ist eine zweistufige Ebenen-Hierarchie definiert. Die Teilbaupläne wie auch der zu erstellende Bauplan SPEC können zum Beispiel als strukturierte XML-Dateien realisiert sein bzw.
werden. Durch die XML-Datenstruktur lässt sich diese mindestens zwei Ebenen umfassende Hierarchie durch entsprechende Schachtelung der bekannten XML-tags <, > abbilden.
Eine Validierungseinheit VAL ist kommunikativ mit dem Rechner PD und einer Regeldatenbank DBV verbunden. In der Regeldatenbank DBV sind zum Beispiel in tabellenartigen Datenstrukturen von den Luftfahrtbundesämtern vorgegebene Regeln gespeichert. Die tabellenartige Datenstruktur umfasst zum Beispiel mindestens zwei Spalten.
Neben diesen Regeln, die insbesondere im Zusammenhang mit den hier nicht näher beschriebenen "Optionen" stehen, werden auch globale Regeln beachtet. Es gibt produktspezifische Regeln, die die Leistungsfähigkeit des Produktes definieren und so "Baubarkeit" garantieren. Beispielsweise wird der Gesamtstromverbrauch der Kabine nicht durch lokale Einschränkungen verwaltet. Im Übrigen kann es auch Regeln geben, welchem Flugzeugmodell und welcher Zone ein Modul zuzuordnen ist.
In einer Spalte sind Identifikatoren für die jeweiligen modifizierbaren Elemente der Teilbaupläne gespeichert. In der zugehörigen Zeile in der zweiten Spalte steht der jeweiligen Spezifikationswerte, zum Beispiel als Code, Zahlenwerte oder als
Zahlenbereich. So kann zum Beispiel eine Farbe für einen Sitzbezug eines Sitzes kodiert sein.
Auf Grundlage der technischen Parameter, die sich aus den Optionen ableiten, erfolgt dann eine Modifikation der entsprechenden Merkmale der bereits vorvalidierten Teilbaupläne. Dies geschieht durch Schreiben des Parameters in das entsprechende Element oder Modulmerkmal an der entsprechenden Stelle in dem XML-kodierten Teilbauplan.
Gemäß einem weiteren Aspekt sind ein oder mehrere der einzelnen Elemente innerhalb der bereits validierten Teilbaupläne entweder untereinander oder mit Elementen in anderen bereits validierten Teilbauplänen verknüpft. Diese
Verknüpfung kann sich auf Modulmerkmale in Moduleben der Modulteilbaupläne erstrecken. Durch Modifikation des Elements erfolgt dann auch eine dynamischautomatische (Mit-)Modifikation der mit diesem Element verknüpften anderen Elemente bzw. Modulmerkmale. Die Setzung dieser Verknüpfung bzw. Links ist dabei regelbasiert ausgebildet und beruhen ebenfalls auf konstruktionstechnisch notwendigen Überlegungen bzw. auf Vorgaben der nationalen Luftfahrtbundesämter.
Die Teilbaupläne werden dann durch den Rechner PD kombiniert. Das Kombinieren kann zum Beispiel dadurch erfolgen, dass die einzelnen XML-Dateien in eine Gesamt-XML-Datei zusammengefasst („merging") wird, oder auch dass die zu kombinierenden Teilbaupläne über Verbindungen („links") verbunden werden.
Das eigentliche Kombinieren der Teilbaupläne erfolgt allerdings nur dann, wenn die Validierungseinheit VAL keine Verletzung der in der Regeldatenbank DBV abgelegten Regeln registriert.
Die Validierungseinheit VAL kann zum Beispiel als„Parser" ausgebildet sein, der die jeweiligen Einträge in den Teilbauplänen durchgeht und die dort
eingeschriebenen Parametern als neue Element- oder Modulmerkmal mit den Werten in der zweiten Spalte der Tabelle in der Regeldatenbank DBV vergleicht. Wird für jedes Merkmal eine Übereinstimmung („match") registriert, das heißt entspricht der vom User eingegebene Wert dem Wert in der zweiten Spalte der Tabelle, gilt die Kombination als validiert. Durch die Verlinkung kann auch eine Modifikation auf Moduleben zur Folge haben, dass die Validierung auch nicht erfolgreich sein kann. Bei Nicht-Erfolg wird ein Signal von der Validierungseinheit VAL an den Rechner PD abgesetzt. Der Rechner PD wird dann ein Warnsignal an den User absetzen und auf eine Eingabe von revidierten Parametern warten. Der so erhaltene Endbauplan SPEC kann dann zum Beispiel in ein geeignetes „Backend" zur Weiterverarbeitung eingespeist werden. Zum Beispiel kann der Endbauplan SPEC an ein Computer- Aided-Design System (CAD) gegeben werden, um einen graphischen Gesamtplan zu erstellen. Dieser kann dann zum Beispiel von einem Ingenieur gegengeprüft werden.
Alternativ oder ergänzend kann der Endbauplan SPEC auch in eine
Steuervorrichtung bzw. Schnittstelle CON gespeist werden, so dass über diese Steuervorrichtung CON eine Fertigungsanlage MANU mit denjenigen Bauteilen beschickt werden kann, die in dem fertigen Bauplan SEPC spezifiziert wurden.
Auch können z. B. Industriefertigungsroboter gesteuert werden, oder
Niederflurfahrzeuge in Lagerhallen, um die in dem Endbauplan SPEC spezifizierten Komponenten oder Bauteile mit den jeweiligen Maßen oder Ausprägungen bereitzustellen bzw. an einem vorbestimmten Zielort zur Endmontage zu liefern.
In den folgenenden Figuren Fig. 2 und Fig. 3 werden zur Einfachheit der Darstellung die Module und Elemente bzw. deren Spezifizierung als Modulteilbaupläne mit demselben Bezugszeichen bezeichnet.
Fig. 2 zeigt einen Überblick über eine modulares Flugzeugbauteil.
Das Flugzeugbauteil ist eine Flugzeugkabine FC.
FC hat einen Grundriss, der aus verschiedenen Zonen A - E besteht.
In diesem Beispiel unterscheiden sich die Zonen dadurch, dass in den Zonen A, C, E Türen angeordnet sind und in den Zonen B, D keine. Verschiedene Sitzgruppenmodule MB, MD sind den jeweiligen Nichttürzonen B,D zuordenbar. Als weitere Module stehen Versorgungsbereiche MC wie zum Beispiel Toilettenkabinen oder Küchenkabinen bereit. Die speziellen Sitzgruppenmodule MA, ME sind dabei für das Cockpit bzw. für den Heckbereich des Flugzeugs E
vorgesehen.
Jedem Sitzgruppenmodul MA, MB, MD und ME sind dabei Kabinenelemente, wie zum Beispiel einzelne Sitzreihen E, zuordenbar, wie in Fig. 3 dargestellt.
Auf Grundlage des User Inputs, der über die Benutzerschnittstelle UI bereitgestellt wird, kann jedes Kabinenelement„Sitzreihe S" modifiziert, das heißt durch eine bestimmte Ausprägung spezifiziert werden. Zum Beispiel würde die Ausprägung „mit Monitor" zu einer modifizierte bzw. individualisierten Sitzreihe SK führen, bei der die Rücklehnen mit Monitoren ausgestattet sind. In Fig. 3 ist der Klarheit wegen nur beispielhaft eine bildliche Darstellung des Teilbauplans des Sitzgruppenmoduls MB mit dem zugehörigen Kabinenelement S aufgeführt. Für die anderen
Kabinenmodule MA, MC - ME gilt Analoges.
Um Rechenzeit bei der Validierung durch die Validierungseinheit VAL zu sparen, erfolgt die Validierung nicht bis hinunter zu der Elementebene. Das ist dadurch möglich, dass die Teilbaupläne in der Datenbank DB bereits vorvalidiert sind. Die Vorvalidierung ist dabei so gewählt, dass die Wahl einer bestimmten Ausprägung für ein bestimmtes Kabinenelement in einem Sitzgruppenmodul zu regeln, in DBV gemäß keine neue Validierung erfordert. Zum Beispiel ist die Sitzreihe E in Fig. 3 regelgemäß in dem Modul MB montiert, um valide bzw. das umfassende Modul MB ist valide, auch wenn das Kabinenelement E in das Kabinenelement EKA mit Monitor ausgestattet/modifiziert wurde. Eine XML Kodierung des Modulteilbauplans MB, kann beispielsweise so aussehen:
< Modul MB: Modulmerkmal MB_l=mb_l, ... >
<Element S: Elementmerkmal S_l=s_l, ...>
>
>
Ein„flag" in dem Elementmerkmal„mit Monitor?" (S_l) ist dann hier auf„ja" (s_l) modifiziert bzw. gesetzt worden.
Gemäß einer erweiterten Ausführungsform ist die Validierungsvorrichtung VEB einstellbar bzw. programmierbar, bis zu welcher Ebenen-Tiefe die Validierung erfolgen soll. Im vorliegenden Beispiel mit den beiden Ebenen Elementebene bzw. Modulebene, erfolgt die Validierung nur auf der Modulebene. Es ist allerdings auch eine Validierungsstrategie mit einer feineren Granularität denkbar, indem zum Beispiel die Kabinenelemente E aus Sub-Elementen entsprechend den jeweiligen individuellen Sitzen zusammengesetzt sind. In diesem Fall hätte man dann drei Ebenen. Die Vorrichtung VEB ist dann so eingerichtet, dass einstellbar ist, ob nur auf der ersten/höchsten (Modulebene), oder auch auf der zweiten (Elementebne) oder auch auf der dritten Ebene (Sub-Elementebene) validiert werden soll.
Erfolgt die Validierung nicht nur auf erster, sondern auch auf zweiter oder dritter Ebene, erlaubt die Vorrichtung VEB eine größere Flexibilität, die allerdings dann auch durch eine intensivere Rechenzeit der Validierungseinheit VAL erkauft wäre. So kann die Vorrichtung VEB optimal an die Bedürfnisse der Rechenkapazität und erforderlichen Flexibilität angepasst werden.
Die Validierungseinheit VAL, der Rechner PD und die Datenbanksysteme DB, DBV bzw. die Benutzeroberfläche UI können jeweils als eigene Hardware- bzw.
Softwaremodule ausgebildet sein.
Gemäß einer Ausführungsform erfolgt die Implementierung auf einem einzigen lokalen Rechner.
Gemäß einer Ausführungsform ist eine Client- Server- Struktur für eine webbasierte Ausführungsform der Validierungsvorrichtung VEB vorgesehen. In diesem Fall erfolgt die Bereitstellung der technischen Spezifikationsdaten über den Kunden (zum Beispiel die Airline, die ein Flugzeug bestellen möchte) von einem Client aus, auf dem die Benutzeroberfläche UI dargestellt wird. Über eine Netzwerkverbindung, wie zum Beispiel dem Internet, erfolgt dann ein Datenaustausch mit dem Rechner PD („Server"). PD steht wiederum über das Netzwerk mit den Datenbanksystemen DBV bzw. DB in Verbindung. Wurde der fertige Bauplan SPEC validiert und kombiniert, kann dieser dann über die Netzwerkverbindung an die Steuereinheit CON geschickt werden, um die weitere Endmontage im Werk MANU zu koordinieren.
Fig. 4 zeigt zur Verdeutlichung ein Flussdiagramm des Verfahrens, das der
Vorrichtung VEB zum computergestützten Erstellen des Bauplans SPEC zugrunde liegt.
In einem ersten Schritt S5 erfolgt ein optionales Modifizieren auf Elementebene. Dabei wird mindestens eines der Elemente E in ein modifiziertes Element EKA überführt, so dass man so ein individualisiertes, also speziell an die Bedürfnisse des Users angepasstes Sitzgruppenmodul, hervorgehend aus dem bereits vorvalidierten Modul MB, erhält. Analoges gilt für die anderen Module MA, MC-ME.
Anschließend erfolgt im Schritt S10 ein Validieren, das einstellbar nur auf der Modulebene erfolgt. Dabei wird die Kombination eines oder mehrerer der Module MA, MC-ME mit dem individualisierten Modul validiert.
Ein optionaler Schritt S15 baut auf einer Verknüpfung der einzelnen Elemente S innerhalb desselben Moduls oder auch mit anderen Elementen in anderen Modulen MA, C-E auf. Ist im vorherigen Schritt S10 eine Modifikation des Elementes S erfolgt, so geschieht automatisch auch eine auf Regeln basierende entsprechende Modifikation der verknüpften Elemente, entweder in demselben oder in den jeweiligen anderen Modulen MA, C-ME. Diese Regeln basieren ebenfalls auf den Regeln der Regeldatenbank DBV. Dieses dynamische Mit-Modifizieren kann zum Beispiel logisch notwendig oder konstruktionstechnisch bedingt sein. Durch diese dynamische Mit-Modifikation ist an dieser Stelle im Work-Flow kein User Input mehr erforderlich. Ansonsten müsste der User jedesmal„händisch nachziehen" und die Merkmal in den anderen Teilbauplänen anpassen. Dadurch kann der
Datenaustauch und somit die Auslastung des Netzwerks miniert werden.
Ist die Validierung erfolgreich, werden die validierten Modulteilbaupläne in Schritt S20 zusammengesetzt, um so einen validierten Endbauplan SPEC zu erhalten.
Anschließend kann die Datenbank DB dann aktualisiert werden, indem hier der validierte Bauplan SPEC abgespeichert wird, zusammen mit einer ID des Kunden. Durch eine iterative Anwendung des oben beschriebenen Verfahrens, kann dann, ausgehend von dem validen Bauplan SPEC als neuer„Teilbauplan", sukzessive ein kompletter Bauplan für das gesamte Flugzeug computergestützt mit der Vorrichtung VEB erstellt werden.
Ergänzend sei darauf hingewiesen, dass„umfassend" und„aufweisend" keine anderen Elemente oder Schritte ausschließt und„eine" oder„ein" keine Vielzahl ausschließt. Ferner sei darauf hingewiesen, dass Merkmale oder Schritte, die mit Verweis auf eines der obigen Ausführungsbeispiele beschrieben worden sind, auch in Kombination mit anderen Merkmalen oder Schritten anderer oben beschriebener
Ausführungsbeispiele verwendet werden können. Bezugszeichen in den Ansprüchen sind nicht als Einschränkungen anzusehen.

Claims

Patentansprüche 1. Ein computergestütztes Verfahren zum Erstellen eines Bauplans für ein modulares Flugzeug aus einzelnen Modulen, auf Grundlage von bereits validierten Modulteilbauplänen für die einzelnen Module,
wobei den jeweiligen Modulteilbauplänen Elemente zugeordnet sind und dadurch eine Hierarchie definiert ist, die eine höhere Modul- und eine tiefere Elementebene umfasst, das Verfahren die folgenden Schritte umfassend:
abhängig von einer Benutzereingabe, Modifizieren (S5) auf der Elementebene eines der Elemente in einem der Modulteilbaupläne um so einen individualisierten Modulteilbauplan zu erhalten;
Validieren (S15), nur auf der Modulebene, einer Kombination eines der Modulteilbaupläne mit dem individualisierten Modulteilbauplan;
bei erfolgreicher Validierung, Zusammensetzen (S20) der Modulteilbaupläne der so validierten Kombination, um den Bauplan zu erhalten.
2. Verfahren aus Anspruch 1, wobei das Element mit einem weiteren Element oder mit einem Merkmal auf Modulebene von einem der Modulteilbaupläne verknüpft ist, das Verfahren weiterhin aufweisend den Schritt:
automatisches und regelbasiertes Mit-Modifizieren (S10) des verknüpften Elements oder des Modulmerkmals sobald der Modifikationsschritt des Elements erfolgt ist.
3. Verfahren aus einem der Ansprüche 1 oder 2, das Verfahren weiterhin aufweisend:
Abhängig von einer weiteren Benutzereingabe, selektives Einstellen ob auch auf Elementebene oder auch auf tieferen Sub-Elementebenen validiert werden soll.
4. Verfahren nach einem der Ansprüche 1-3, wobei das Flugzeugbauteil eine Flugzeugkabine ist.
5. Verfahren nach einem der Ansprüche 1-4, wobei die Module
Passagiersitzreihengruppen sind.
6. Verfahren nach Anspruch 5, wobei die Elemente einzelne Passagiersitze sind.
7. Verfahren nach einem der Ansprüche 1-4, wobei die Module Küchenmodule oder Toilettenmodule, Notfallausrüstung, Flugkabinenpersonalsitze,
Kabineninnenverkleidung, die auch konfigurierbar sein kann, z. B. mit und ohne Gepäckfächer, sind.
8. Ein Programmelement, das, wenn es auf einem Prozessor ausgeführt wird, den Prozessor steuert, so das ein computergestütztes Verfahren auf dem Prozessor implementierbar ist zum Erstellen eines Bauplans für ein modulares
Flugzeugbauteile aus einzelnen Modulen, auf Grundlage von bereits validierten Modulteilbauplänen für die einzelnen Module,
wobei den jeweiligen Modulteilbauplänen Elemente zugeordnet sind und dadurch eine Hierarchie definiert ist, die eine höhere Modul- und eine tiefere Elementebene umfasst, wobei der so gesteuerte Prozessor dann die folgenden Schritte ausführt:
abhängig von einer Benutzereingabe, Modifizieren auf der Elementebene eines der Elemente in einem der Modulteilbaupläne um so einen individualisierten Modulteilbauplan zu erhalten;
Validieren, nur auf der Modulebene, einer Kombination eines der
Modulteilbaupläne mit dem individualisierten Modulteilbauplan;
bei erfolgreicher Validierung, Zusammensetzen der Modulteilbaupläne der so validierten Kombination, um den Bauplan zu erhalten.
9. Ein elektronischer Datenträger auf dem ein Programmelement nach Anspruch 8 gespeichert ist.
10. Ein oder mehrere elektronische Datenträger auf denen gespeichert sind: bereits validierte Modulteilbaupläne für einzelnen Module eines modularen
Flugzeugbauteils, wobei den jeweiligen Modulteilbauplänen Elemente zugeordnet sind und dadurch eine Hierarchie definiert ist, die eine höhere Modul- und eine tiefere Elementebene umfasst; und
Instruktionen, die, wenn von einem Prozessor ausgeführt, geeignet sind ein computergestütztes Verfahren zum Erstellen eines Bauplans für das modulare
Flugzeugbauteil auf dem Prozessor zu implementieren, wobei der Prozessor dann die folgenden Schritte ausführt:
abhängig von einer Benutzereingabe, Modifizieren auf der Elementebene eines der Elemente in einem der Modulteilbaupläne um so einen individualisierten Modulteilbauplan zu erhalten;
Validieren, nur auf der Modulebene, einer Kombination eines der
Modulteilbaupläne mit dem individualisierten Modulteilbauplan;
bei erfolgreicher Validierung, Zusammensetzen der Modulteilbaupläne der so validierten Kombination, um den Bauplan zu erhalten.
11. Eine Vorrichtung (VEB) zum computergestützten Erstellen eines Bauplans (SPEC) für modulare Flugzeugbauteile (FC) aus einzelnen Modulen auf Grundlage von bereits validierten Teilbauplänen (MA-ME), für die einzelnen Module,
wobei den jeweiligen Modulteilbauplänen (MA-ME), Elemente (S) zugeordnet sind und dadurch eine Hierarchie definiert ist, die eine höhere Modul- und eine tiefere Elementebene umfasst, die Vorrichtung umfassend:
eine Datenbank (DB) auf der die bereits validierten Modulteilbaupläne als elektronische Datenstrukturen hinterlegt sind, wobei die Datenstrukturen geeignet sind die zwei oder mehre Ebenen umfassende Hierarchie abzubilden;
eine Benutzerschnittselle (UI) zum Erfassen einer Benutzereingabe; ein Prozessor (PD) eingerichtet um auf der Elementebene und abhängig von der Benutzereingabe eines der Elemente in einen der Modulteilbauplan zu modifizieren um so ein individualisiertes Modul zu erhalten;
eine Regeldatenbank (DBV) auf der Validierungsregeln gespeichert sind; eine Validierungseinheit (VAL) die eingerichtet und konfiguriert ist um eingeschränkt auf die Modulebene und auf Grundlage der Validierungsregeln, eine Kombination von einem oder mehrerer der Modulteilbaupläne mit dem
individualisierten Modulteilbauplan zu validieren, so dass, bei erfolgreicher
Validierung, der Prozessor die Modulteilbaupläne der so validierten Kombination zusammensetzen kann, um so den Bauplan zu erhalten.
12. Vorrichtung nach Anspruch 11, wobei das Element mit einem weiteren Element oder mit einem Merkmal auf Modulebene von einem der Modulteilbaupläne verknüpft ist, wobei der Prozessor so konfiguriert ist, dass das verknüpfte Element oder das Modulmerkmal automatisch und regelbasiert mit-modifiziert wird, sobald die Modifikation des Elements erfolgt ist.
13. Vorrichtung nach einem der Ansprüche 11-12, wobei die Validierungseinheit konfigurierbar ist, so dass selektiv einstellbar ist, ob auch auf der Elementebene oder auch auf tieferen Sub-Elementebenen validiert werden soll.
14. Vorrichtung nach einem der Ansprüche 11-13, weiter umfassend eine Kontrolleinheit, die eingerichtet ist, um auf Grundlage des erstellten Bauplans eine Fertigungsanlage für Flugzeuge zu steuern bzw. zu verwalten.
15. Eine industrielle Fertigungsanlage zur Montage eines Flugzeuges, die steuerbar bzw. verwaltbar ist von einer Vorrichtung nach einem der Ansprüche 11- 14.
EP10749658A 2009-09-09 2010-09-07 Konfigurationsgesteuerte dynamische erzeugung von produktdaten für komplexe produkte Ceased EP2476072A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US24077609P 2009-09-09 2009-09-09
DE102009040731A DE102009040731A1 (de) 2009-09-09 2009-09-09 Konfigurationsgesteuerte dynamische Erzeugung von Produktdaten für komplexe Produkte
PCT/EP2010/063112 WO2011029819A1 (de) 2009-09-09 2010-09-07 Konfigurationsgesteuerte dynamische erzeugung von produktdaten für komplexe produkte

Publications (1)

Publication Number Publication Date
EP2476072A1 true EP2476072A1 (de) 2012-07-18

Family

ID=43571100

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10749658A Ceased EP2476072A1 (de) 2009-09-09 2010-09-07 Konfigurationsgesteuerte dynamische erzeugung von produktdaten für komplexe produkte

Country Status (4)

Country Link
US (1) US8560287B2 (de)
EP (1) EP2476072A1 (de)
DE (1) DE102009040731A1 (de)
WO (1) WO2011029819A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009058802B4 (de) * 2009-12-18 2018-03-29 Airbus Operations Gmbh Anordnung zur kombinierten Darstellung eines realen und eines virtuellen Modells
DE102010021638A1 (de) * 2010-04-14 2011-10-20 Airbus Operations Gmbh Verfahren zur Konfiguration und/oder Bestückung einer Kabine eines Luftfahrzeugs
US20130246008A1 (en) * 2012-03-15 2013-09-19 Chao-Hsin Lin Cabin airflow modeling
FR3021775A1 (fr) * 2014-05-27 2015-12-04 Defacto Dispositif et procede de modelisation numerique en trois dimensions
WO2016141101A1 (en) * 2015-03-02 2016-09-09 C & D Zodiac, Inc. Design optimizer system and methods
EP3101565A1 (de) * 2015-06-01 2016-12-07 Airbus Operations GmbH Flugzeuganordnungssystem

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5106290A (en) * 1987-04-14 1992-04-21 Northrop Corporation Assembly data model tool system
US7043407B2 (en) * 1997-03-10 2006-05-09 Trilogy Development Group, Inc. Method and apparatus for configuring systems
US6952705B2 (en) * 1997-03-25 2005-10-04 Mci, Inc. Method, system and program product that utilize a hierarchical conceptual framework to model an environment containing a collection of items
DE10041031A1 (de) * 2000-08-22 2002-03-21 Airbus Gmbh Verfahren zur Konfiguration von Komponentenanordnungen und zur Generierung von Herstellungsunterlagen
CA2625280C (en) * 2001-08-09 2010-08-03 Virgin Atlantic Airways Limited A seating system and a passenger accomodation unit for a vehicle
US6922599B2 (en) * 2001-08-13 2005-07-26 The Boeing Company System and method for producing an assembly by directly implementing three-dimensional computer-aided design component definitions
US7529649B2 (en) * 2004-03-18 2009-05-05 The Boeing Company System and method for knowledge based interior development
US20080162217A1 (en) * 2004-06-14 2008-07-03 Symphonyrpm, Inc. Decision object for associating a plurality of business plans
US8402007B2 (en) * 2005-08-02 2013-03-19 The Boeing Company Methods and apparatus for creating and utilizing templates in connection with information modeling
US20080004843A1 (en) * 2006-06-30 2008-01-03 Airbus Espana, S.L. System and method for performing a Zonal Safety Analysis in aircraft design
US20090030661A1 (en) * 2007-07-25 2009-01-29 The Boeing Company Three-Dimensional Process Planning
US8090462B2 (en) * 2007-12-19 2012-01-03 Mobideo Technologies Ltd Maintenance assistance and control system method and apparatus

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2011029819A1 *

Also Published As

Publication number Publication date
US8560287B2 (en) 2013-10-15
DE102009040731A1 (de) 2011-03-17
WO2011029819A1 (de) 2011-03-17
US20120173210A1 (en) 2012-07-05

Similar Documents

Publication Publication Date Title
DE102011016293A1 (de) Verfahren zur Konfiguration und/oder Bestückung einer Fahrzeugkabine, insbesondere eines Luftfahrzeugs
DE102009043327B4 (de) System und Verfahren zur Konfiguration einer Flugzeugpassagierkabine
WO2011029819A1 (de) Konfigurationsgesteuerte dynamische erzeugung von produktdaten für komplexe produkte
EP1182527A2 (de) Verfahren zur automatischen Konfiguration von Komponentenanordnungen und zur automatischen Generierung von Herstellungsunterlagen
DE69910174T2 (de) Wissensbasierter Entwurfsoptimierungsprozess für Verbundwerkstoffe und System dafür
EP1917611A2 (de) System für den maschinengestützten entwurf technischer vorrichtungen
DE102015117181A1 (de) Luftfahrzeugrekonfigurator zum Rekonfigurieren einer Luftfahrzeugkonfiguration
DE102021004346A1 (de) Verfahren zum Aufbau und zur Pflege einer Fahrzeugtypbibliothek
WO2026017216A1 (de) Verfahren zum durchführen einer simulation für die erzeugung eines geometrischen bauteils, computerprogrammprodukt sowie elektronische recheneinrichtung
EP3831717B1 (de) Verfahren zum automatisierten auswählen und anordnen einer mehrzahl von strukturellen elementen in einem begrenzten raum
DE212021000505U1 (de) Generator für Fluidverteilungssystemlösung
DE102021208368A1 (de) Computerimplementiertes Verfahren zur Entwicklung eines Produkts in einem vernetzten System und Anwendersystem zur computergestützten Entwicklung eines Produkts
WO2007079759A1 (de) Verfahren und vorrichtung zum konstruieren eines formteils
Morar Additive Manufacturing
Zemke Extension of a knowledge-based design system for the fuselage integration of future cargo aircraft
DE202019004398U1 (de) Systemarchitektur zur Berechnung von Flugdaten
DE19955002C2 (de) Modellierungsverfahren für Informationsmodelle zur konsistenten Repräsentation und/oder Speicherung von Systemelementen hierarchischer Systemstrukturen
DE102018131540A1 (de) Erstellen von Steuerungsdaten für eine Schichtaufbauvorrichtung
WO2004081682A1 (de) Verfahren zur auslegung und konstruktion von komplexen technischen produkten
AT501214B1 (de) Verfahren zur auslegung und konstruktion von komplexen technischen produkten
DE102020214362A1 (de) Verfahren zum Verwalten von Daten von einer Vielzahl von Entitäten und Vorrichtung zur Datenverarbeitung
DE102024200848A1 (de) Verfahren zum Übertragen von Eigenschaften auf ein CAD-Model
DE102024103861A1 (de) Verfahren zum Erzeugen von Softwarekomponenten
WO2021121984A1 (de) Verfahren und system zur evaluierung einer verwendbarkeit eines neuen basiselements
DE102023108080A1 (de) System und Verfahren zum Erzeugen von Aussparungen in einem Bauteil

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20120306

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: SCHMIDT-SCHAEFFER, TOBIAS

Inventor name: SCHILLER, ULF

Inventor name: BECKER, BENJAMIN

Inventor name: AMADOR, MILTON

Inventor name: SEIFERT, ULRICH

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20150728

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20210614