View source for Interface Management and System Integration in Collaborative Aircraft Design

= Interface Management and System Integration in Collaborative Aircraft Design =

== Summary ==

Interface management is one of the most important disciplines in collaborative aircraft design. It ensures that the work produced by different teams, schools, tools and engineering domains can be assembled into a coherent system. In upstream aerospace projects, especially from TRL 1 to TRL 3, integration issues often appear before final performance issues. A wing may be well designed, a loading mechanism may be clever, a software module may work in isolation, but the aircraft or system can still fail if the interfaces are not properly defined.

In Bee ecosystem projects such as Bee-Plane, ISO-Plane, Mini-Bee and GPS 4D, interfaces are everywhere. Bee-Plane depends on the connection between the Bee carrier and the detachable Basket. ISO-Plane depends on the interface between the cargo bay, the container, the lifting system, the aircraft structure and the ground operation sequence. Mini-Bee depends on the interfaces between rotors, power chain, sensors, flight controls, cockpit and structure. GPS 4D depends on the interfaces between trajectory algorithms, maps, weather data, airspace constraints, real-time visualization and data exchange formats.

This page provides a practical method for managing interfaces and system integration in collaborative aircraft design. It is written for student teams, academic partners and early-stage aerospace contributors working under the Lesser Open Bee License 1.3. Its purpose is to help teams move from isolated deliverables to reusable, traceable and integrated engineering work.

== 1. Why interfaces matter in upstream aerospace projects ==

Aircraft design is not a set of independent technical exercises. It is a system of coupled decisions. A change in one domain often affects several others.

For example:

* a change in payload modifies mass, centre of gravity, structure and performance;
* a change in wing position modifies stability, landing gear placement and engine integration;
* a change in cockpit layout modifies sensors, displays, wiring, ergonomics and safety;
* a change in cargo-door geometry modifies structure, loading operations and certification assumptions;
* a change in data format modifies software integration, visualization, simulation and future reuse.

At early TRL levels, teams often work in separate work packages: aerodynamics, structure, propulsion, cockpit, market study, CAD, simulation, software, project management. This division is useful, but it creates a major risk: each team may optimize its own subsystem without checking how it connects to the rest of the aircraft or platform.

Interface management reduces this risk. It defines what each subsystem expects from others, what it provides to others, and what constraints must remain stable for integration to succeed.

== 2. What is an interface? ==

An interface is a boundary where two systems, teams, files, components or functions interact.

In aerospace projects, interfaces can be:

{| class="wikitable"
! Interface type
! Examples
|-
| Mechanical interface
| Bolts, pins, rails, attachment points, load paths, hinges, brackets, landing gear supports
|-
| Geometrical interface
| CAD reference planes, fuselage cut-outs, cargo-bay dimensions, wing position, envelope constraints
|-
| Structural interface
| Load transfer, pressure loads, bending moments, crash loads, payload supports
|-
| Aerodynamic interface
| Wing-body junction, engine flow, rotor wake, fairings, detachable module effects
|-
| Electrical interface
| Voltage levels, connectors, buses, wiring paths, power distribution
|-
| Software interface
| APIs, data formats, message protocols, JSON, XML, GeoJSON, WebSocket, simulation inputs
|-
| Human-machine interface
| Cockpit displays, alerts, pilot controls, maintenance access, operator interface
|-
| Operational interface
| Loading, unloading, inspection, taxiing, maintenance, turnaround, emergency procedures
|-
| Documentation interface
| File naming, version control, metadata, README files, change logs and wiki links
|-
| Organizational interface
| Responsibilities between schools, work packages, reviewers and future teams
|}

An interface is not only a physical connection. It is also an agreement.

== 3. Interface management as a project-management function ==

Interface management is not only a technical task. It is also a project-management function. The project manager must ensure that interface questions are visible, assigned and reviewed regularly.

Good interface management helps answer:

* Which subsystem provides the information?
* Which subsystem uses the information?
* Who owns the interface?
* Which file is the reference?
* Which assumptions are frozen?
* Which assumptions may still change?
* What happens if one interface changes?
* Which teams must be informed?
* How is the interface verified?
* Where is the interface documented?

For student teams, this is especially important because work is often distributed over short academic periods. A future team may not know why a dimension, format or layout was chosen unless the interface is clearly documented.

== 4. Interface examples in Bee projects ==

=== 4.1 Bee-Plane: Bee/Basket interface ===

Bee-Plane is built around a detachable architecture. The Bee carrier includes the cockpit, wings, engines, landing gear and main flying functions. The Basket carries passengers, freight or specialized mission equipment. The central interface is therefore the connection between the Bee and the Basket.

This interface is not only mechanical. It includes:

* load transfer between Basket and Bee;
* alignment during attachment;
* locking or fastening system;
* emergency detachment assumptions;
* ground-handling sequence;
* aerodynamic continuity;
* passenger or cargo safety;
* maintenance accessibility;
* fuel, electrical or data connections if applicable;
* operational checks before flight.

If this interface is poorly defined, each team may produce a coherent subsystem but an incoherent aircraft.

=== 4.2 ISO-Plane: cargo bay, container and loading interface ===

ISO-Plane is designed around the ability to transport a 20-foot ISO container and to manipulate it with limited external assistance. This creates several critical interfaces:

* container-to-cargo-bay geometry;
* container-to-floor load transfer;
* lifting system-to-aircraft structure;
* doors-to-fuselage structure;
* loading sequence-to-ground vehicle;
* cockpit command-to-loading mechanism;
* structural beams-to-removable floor;
* cargo mission-to-aerodynamic configuration.

The loading system cannot be designed separately from the cargo bay. The cargo bay cannot be designed separately from the structure. The structure cannot be designed separately from the mass budget and aerodynamic configuration.

=== 4.3 Mini-Bee: power, controls and rotor interfaces ===

Mini-Bee combines rotor performance, power chain, sensors, cockpit instrumentation, structure and safety logic. It is a strong example of interface complexity.

Critical interfaces include:

* thermal engine or generator to electrical power chain;
* power chain to distributed rotors;
* sensors to flight controller;
* flight controller to servos or motor commands;
* cockpit display to pilot decision-making;
* rotor groups to structural frame;
* landing gear or skids to lower structure;
* emergency systems to cockpit alerts;
* transportability constraints to modular structure.

A rotor or power-chain decision may affect mass, wiring, structural layout, redundancy, control laws and cockpit display requirements.

=== 4.4 GPS 4D: data and software interfaces ===

GPS 4D is a data-driven system. Its core interfaces are not mainly mechanical, but digital and operational.

Important interfaces include:

* aircraft performance database to trajectory algorithm;
* map data to visualization engine;
* airspace restrictions to route planning;
* weather data to dynamic cost functions;
* real-time position to display;
* collision detection to alert system;
* simulation server to web interface;
* data model to external tools;
* future aircraft systems to exchange format.

For GPS 4D, interface management means defining shared data structures. Without shared formats, each component may work alone but fail during integration.

== 5. The interface-management mindset ==

A good interface manager asks questions before integration fails.

Examples:

* What does this subsystem need from others?
* What does it provide to others?
* Which assumptions are shared?
* Which dimensions must not change without review?
* Which data fields are mandatory?
* Which loads are transmitted?
* Which file is authoritative?
* Which team is responsible for updates?
* What is the verification evidence?
* What happens if this interface is wrong?

The interface-management mindset is not about blocking creativity. It is about making creativity compatible with system-level design.

== 6. Interface Control Document (ICD) ==

The most useful document for interface management is the Interface Control Document, often called ICD.

An ICD describes one interface or a family of interfaces. It should be clear enough for another team to reuse without asking the original authors for hidden explanations.

A simple ICD should include:

{| class="wikitable"
! Field
! Description
|-
| Interface name
| Short name of the interface
|-
| Interface ID
| Unique identifier
|-
| Subsystem A
| First subsystem or team
|-
| Subsystem B
| Second subsystem or team
|-
| Interface type
| Mechanical, structural, electrical, software, operational, documentation, etc.
|-
| Owner
| Team responsible for maintaining the interface
|-
| Inputs
| What the interface receives
|-
| Outputs
| What the interface provides
|-
| Geometry
| Dimensions, reference planes, tolerances, envelopes
|-
| Loads
| Forces, moments, pressure, mass or acceleration assumptions
|-
| Data
| File format, units, coordinate systems, update frequency
|-
| Constraints
| Safety, certification, operational or design constraints
|-
| Verification
| Analysis, CAD review, simulation, test or inspection
|-
| Status
| Draft, proposed, frozen, verified, obsolete
|-
| Related files
| CAD, reports, simulation files, wiki links
|-
| Change history
| Version, date, modification and reason
|}

An ICD should be short, but precise. It should avoid hidden assumptions.

== 7. Interface matrix ==

An interface matrix is a simple table showing which work packages interact. It is useful at the beginning of the project because it reveals dependencies.

{| class="wikitable"
! Subsystem
! Structure
! Aerodynamics
! Propulsion
! Cockpit
! Software
! Operations
|-
| Structure
| —
| Loads and external shape
| Engine mounts and vibration
| Seat, controls and display supports
| Sensor mounting
| Maintenance and access
|-
| Aerodynamics
| Pressure loads and fairings
| —
| Inlet flow, rotor wake or propeller effects
| Visibility constraints
| Performance model
| Take-off and landing scenarios
|-
| Propulsion
| Mounts and thermal constraints
| Drag and flow quality
| —
| Engine monitoring
| Control and power data
| Refuelling and maintenance
|-
| Cockpit
| Ergonomics and supports
| Visibility and glazing
| Engine controls
| —
| Displays and alerts
| Pilot procedures
|-
| Software
| Sensor installation
| Performance model
| Power and control signals
| Human-machine interface
| —
| Mission planning
|-
| Operations
| Ground loads and accessibility
| Airport compatibility
| Refuelling and energy supply
| Crew procedures
| Route and scenario data
| —
|}

This matrix can be adapted for each project. Its goal is to identify where coordination is required.

== 8. Interface ownership ==

Every important interface should have an owner. Without ownership, interface decisions become informal and may be lost.

The owner does not necessarily design both sides of the interface. The owner is responsible for:

* maintaining the interface document;
* collecting constraints from both sides;
* organizing reviews;
* updating versions;
* warning teams when the interface changes;
* ensuring that verification evidence exists.

For example:

* Bee/Basket attachment interface: structure or system-integration team.
* ISO container loading interface: cargo-system or configuration team.
* Mini-Bee sensor-to-flight-controller interface: avionics or control team.
* GPS 4D data-exchange interface: software architecture or data-model team.

== 9. Integration levels ==

System integration should be progressive. A team should not wait until the final presentation to discover integration problems.

Recommended integration levels:

{| class="wikitable"
! Level
! Description
! Example
|-
| Level 0 — Assumption alignment
| Teams agree on shared assumptions
| Mass, payload, speed, coordinate system, mission profile
|-
| Level 1 — Document integration
| Reports and requirements are consistent
| Same aircraft version used in all documents
|-
| Level 2 — CAD integration
| Geometry files fit together
| Wing, fuselage, landing gear and cargo bay align
|-
| Level 3 — Data integration
| Software and simulation files exchange usable data
| JSON, CSV or GeoJSON files read by several tools
|-
| Level 4 — Simulation integration
| Subsystem models work together
| Trajectory model uses aircraft performance and weather data
|-
| Level 5 — Operational integration
| The complete mission sequence is coherent
| Loading, taxiing, take-off, cruise, landing and unloading are compatible
|-
| Level 6 — TRL evidence integration
| Results are packaged for review
| Requirements, risks, simulations and recommendations are connected
|}

This staged approach makes integration manageable for student teams.

== 10. CAD interface management ==

CAD models are often the first visible integration point. However, CAD can also hide many errors.

Good CAD interface practices include:

* use shared reference planes;
* define a common coordinate system;
* define origin, axes and units;
* freeze key dimensions at each project milestone;
* separate concept geometry from detailed parts;
* document envelope constraints;
* avoid local-only files;
* export neutral formats such as STEP;
* identify derived models;
* include a README describing model assumptions.

For modular aircraft, CAD interfaces are especially important. A detachable Basket, removable floor, cargo-bay door, rotor frame or cockpit panel must be positioned relative to stable reference geometry.

== 11. Mechanical and structural interfaces ==

Mechanical interfaces must define not only shape, but also forces and operational conditions.

A mechanical interface document should include:

* attachment points;
* load cases;
* degrees of freedom;
* tolerances;
* safety factors;
* materials;
* assembly sequence;
* inspection method;
* failure assumptions;
* maintenance access;
* compatibility with surrounding geometry.

For early TRL projects, exact certified values are not always available. The team should still document first assumptions and identify what must be validated later.

Example:

:''The Basket-to-Bee mechanical interface shall transmit vertical, longitudinal and lateral loads defined in the current mass and manoeuvre assumptions. The interface shall be documented with attachment geometry, preliminary load paths and inspection assumptions.''

== 12. Electrical and power interfaces ==

Electrical interfaces are critical in projects involving sensors, propulsion, cockpit systems, avionics or hybrid power chains.

The interface document should define:

* voltage levels;
* current levels;
* connectors;
* bus type;
* signal type;
* power budget;
* redundancy assumptions;
* thermal constraints;
* grounding assumptions;
* failure modes;
* test method.

In Mini-Bee-like projects, power interfaces can strongly affect mass, safety, system architecture and cockpit display logic. A propulsion or rotor decision cannot be isolated from power distribution and control interfaces.

== 13. Software and data interfaces ==

Software interfaces are central for GPS 4D and increasingly relevant for all modern aircraft projects.

Software interface documentation should include:

* data format;
* field names;
* units;
* coordinate system;
* update frequency;
* timestamp format;
* data source;
* error handling;
* API or message structure;
* version number;
* test examples.

Example of a simple data interface:

{| class="wikitable"
! Field
! Type
! Unit
! Description
|-
| aircraft_id
| string
| —
| Unique aircraft identifier
|-
| latitude
| number
| degrees
| Geographic latitude
|-
| longitude
| number
| degrees
| Geographic longitude
|-
| altitude
| number
| meters or feet
| Aircraft altitude, unit must be specified
|-
| timestamp
| string
| ISO time
| Time associated with the position
|-
| velocity
| number
| m/s
| Aircraft speed
|-
| status
| string
| —
| Normal, warning, emergency or simulation
|}

For collaborative software work, the data model is itself an interface contract.

== 14. Operational interfaces ==

An aircraft concept is not only a flying object. It is also an operational system.

Operational interfaces include:

* passenger boarding;
* cargo loading;
* container lifting;
* ground inspection;
* refuelling or charging;
* maintenance access;
* cockpit preparation;
* emergency procedure;
* airport compatibility;
* turnaround sequence.

For Bee-Plane, the operational interface between Basket preparation and Bee availability is central to the concept. For ISO-Plane, the operational interface between aircraft, container, loading system and ground vehicle is central. For Mini-Bee, the operational interface between emergency mission, cockpit, medical equipment and landing zone is central.

A good integration review should always include an operational sequence.

== 15. Human-machine interfaces ==

The human-machine interface is the boundary between technical systems and human decisions.

In early aerospace projects, HMI issues may include:

* what the pilot sees;
* what the operator sees;
* what warnings are displayed;
* what information is always visible;
* what information appears only in emergency;
* how control modes are selected;
* how automation is monitored;
* how degraded modes are understood;
* how maintenance teams inspect system status.

Mini-Bee cockpit studies and GPS 4D interface studies show that display choices are not cosmetic. They influence safety, workload, acceptability and mission effectiveness.

== 16. Interface reviews ==

Interface reviews should be scheduled regularly. They do not need to be long, but they must be explicit.

A good interface review asks:

* Which interfaces changed since the last review?
* Which teams are affected?
* Which assumptions are still open?
* Which files are the current references?
* Which interfaces are blocking progress?
* Which interfaces are high risk?
* Which interfaces need Coordinator or expert review?
* What must be frozen before the next milestone?

A recommended review rhythm for student projects:

* initial interface mapping during project launch;
* interface review after first WBS;
* interface review before main CAD modelling;
* interface review before simulation;
* interface review before final report;
* interface review before publishing to the wiki.

== 17. Interface risks ==

Many project failures are interface failures.

Typical interface risks include:

{| class="wikitable"
! Risk
! Consequence
! Mitigation
|-
| Different teams use different mass assumptions
| Inconsistent aerodynamic, structural and propulsion results
| Publish a shared mass baseline
|-
| CAD coordinate systems are not aligned
| Assembly errors and geometry conflicts
| Define common origin, axes and units
|-
| Software modules use different data formats
| Integration failure
| Define a data dictionary and test files
|-
| Loading mechanism not coordinated with structure
| Unrealistic cargo concept
| Create a joint cargo-structure ICD
|-
| Cockpit display not linked to sensor architecture
| Missing or unusable information
| Define signal flow and display requirements
|-
| Interface changes are not communicated
| Obsolete deliverables
| Maintain a changelog and review process
|-
| External tool assumptions are undocumented
| Results cannot be reproduced
| Publish configuration notes and input files
|}

Interface risks should be tracked in the project risk register.

== 18. Interface management and WBS ==

The Work Breakdown Structure should include interface tasks explicitly.

Examples:

* define Bee/Basket mechanical interface;
* define cargo loading sequence;
* define aircraft coordinate system;
* define cockpit data flow;
* define sensor-to-controller interface;
* define trajectory data model;
* define CAD export format;
* define simulation input/output files;
* define operational sequence;
* define interface verification plan.

If interface tasks do not appear in the WBS, they are often forgotten.

== 19. Interface management and RACI ==

A RACI matrix helps clarify responsibilities.

{| class="wikitable"
! Interface task
! Responsible
! Accountable
! Consulted
! Informed
|-
| Define CAD reference system
| Configuration team
| Project manager
| Structure, aerodynamics, CAD teams
| All teams
|-
| Define cargo-loading interface
| Cargo-system team
| System integration lead
| Structure, operations, market team
| Project manager
|-
| Define sensor data format
| Avionics/software team
| Software lead
| Cockpit, control, simulation teams
| All software users
|-
| Define aerodynamic load transfer
| Aerodynamics team
| Technical lead
| Structure team
| Project manager
|-
| Define final documentation interface
| Documentation team
| Project manager
| All work packages
| Future teams
|}

The exact roles may vary, but every interface must have responsibility and accountability.

== 20. Change control ==

Interfaces must be controlled because a small change can affect many teams.

A change-control process should include:

# Identify the proposed change.
# Describe the reason.
# Identify affected interfaces.
# Inform affected teams.
# Assess technical impact.
# Assess schedule impact.
# Update the ICD.
# Update related CAD, simulation or data files.
# Record the change in the changelog.
# Validate the new baseline.

For student projects, this can be simple. A shared changelog and a review slide may be enough if they are maintained seriously.

== 21. Integration evidence for TRL reviews ==

At TRL 1–3, integration evidence does not need to be a fully working prototype. It can include:

* interface matrix;
* ICDs;
* integrated CAD assembly;
* common coordinate system;
* compatible data files;
* simulation chain;
* load-transfer diagram;
* operational sequence;
* interface risk register;
* verification matrix;
* integration review minutes;
* TRL evidence package.

A project claiming TRL progress should be able to show not only subsystem work, but also evidence that subsystems can connect.

== 22. Documentation standards for interfaces ==

Interface documentation should be easy to find and easy to reuse.

Recommended file structure:

<pre>
/docs
  Interface_Control_Documents/
  Requirements/
  Review_Minutes/

/models
  CAD_Reference/
  STEP_Exports/
  Assembly_Files/

/simulations
  Inputs/
  Outputs/
  Configuration_Files/

/data
  Data_Dictionary/
  JSON_Examples/
  GeoJSON_Examples/
  CSV_Exports/

/reports
  TRL_Evidence/
  Final_Reports/

/media
  Figures/
  Diagrams/
</pre>

Each folder should include a README when necessary.

Recommended file naming:

<pre>
Project_Interface_SubsystemA_SubsystemB_TTL_Year_Version.ext
BeePlane_Interface_Bee_Basket_TRL2_2026_v01.pdf
ISOPlane_Interface_CargoBay_LoadingSystem_TRL2_2026_v01.step
GPS4D_Interface_Trajectory_DataModel_TRL2_2026_v01.json
MiniBee_Interface_Sensors_FlightController_TRL2_2026_v01.xlsx
</pre>

== 23. Interface checklist before publishing ==

Before publishing an interface page or document, verify that it includes:

* project name;
* TRL level;
* date;
* version number;
* interface name;
* interface owner;
* subsystems involved;
* interface type;
* assumptions;
* geometry or data definition;
* units;
* constraints;
* reference files;
* verification method;
* open issues;
* risks;
* change history;
* next actions;
* license reference.

== 24. Recommended deliverables for an interface work package ==

{| class="wikitable"
! Deliverable
! Purpose
|-
| Interface matrix
| Shows subsystem dependencies
|-
| Interface Control Document
| Defines one critical interface in detail
|-
| Data dictionary
| Defines fields, units and formats for software/data exchanges
|-
| CAD reference note
| Defines coordinate system, reference geometry and export formats
|-
| Integration risk register
| Tracks interface-related risks
|-
| Operational sequence
| Shows how the system is used in real conditions
|-
| Integrated CAD assembly
| Demonstrates geometry compatibility
|-
| Simulation chain diagram
| Shows how models exchange inputs and outputs
|-
| Change log
| Records interface modifications
|-
| TRL integration evidence note
| Summarizes integration proof for reviews
|}

== 25. Suggested Interface Control Document template ==

<pre>
= Interface Control Document – Interface Name – Project – TRL Level =

== Summary ==
Short description of the interface and why it matters.

== Interface Identification ==
Interface ID:
Subsystem A:
Subsystem B:
Interface owner:
Version:
Date:

== Scope ==
What is included and what is excluded.

== Interface Type ==
Mechanical, structural, electrical, software, aerodynamic, operational, documentation or organizational.

== Assumptions ==
Mass, geometry, units, coordinate system, load cases, mission scenario or data assumptions.

== Geometry or Data Definition ==
Dimensions, reference planes, coordinates, file formats, fields, units or protocols.

== Inputs and Outputs ==
What each subsystem provides and receives.

== Constraints ==
Safety, operational, environmental, regulatory, manufacturing or tool constraints.

== Verification Method ==
Analysis, CAD review, simulation, inspection, test or expert review.

== Risks and Open Points ==
Unresolved questions and high-risk assumptions.

== Related Files ==
CAD, reports, simulation files, data files and wiki links.

== Change Log ==
Version history.

== Next Actions ==
What future teams should update, validate or test.

== License Reference ==
Task achieved under the Lesser Open Bee License 1.3 Chapter 2 Open source – © Coordinator Technoplane SAS.
</pre>

== 26. Common mistakes in interface management ==

=== Mistake 1 — Treating interfaces as details ===

Interfaces are not details. They are where subsystems become a system.

=== Mistake 2 — Waiting until the end to integrate ===

Late integration creates surprises. Early interface mapping prevents major rework.

=== Mistake 3 — Not defining units ===

A data field without units is dangerous. A dimension without units is unusable.

=== Mistake 4 — Using local CAD references ===

CAD models must share a common coordinate system and reference geometry.

=== Mistake 5 — Not documenting assumptions ===

An interface based on hidden assumptions cannot be reused.

=== Mistake 6 — Changing an interface without informing others ===

Every interface change should trigger communication with affected teams.

=== Mistake 7 — Forgetting operational interfaces ===

An aircraft may be technically coherent but operationally unusable if loading, maintenance or emergency sequences are not considered.

== 27. Good practices for collaborative teams ==

For Bee projects, interface management should follow these good practices:

* create an interface matrix early;
* assign owners to critical interfaces;
* document interface assumptions;
* use open formats;
* maintain a changelog;
* connect interfaces to requirements;
* connect interfaces to WBS tasks;
* review interfaces at each milestone;
* publish final interface documents on the wiki;
* prepare future teams to continue the work.

This supports transparency, reuse and continuity between cohorts.

== 28. Conclusion ==

Interface management is the discipline that transforms separate engineering contributions into a coherent aircraft or system. It is especially important in collaborative aerospace projects where several teams, schools and technical domains work on the same concept.

In Bee-Plane, the Bee/Basket interface is central to the aircraft concept. In ISO-Plane, the container, cargo bay, loading system and structure must be integrated from the beginning. In Mini-Bee, the rotors, power chain, sensors, cockpit and structure are deeply coupled. In GPS 4D, the system exists through data interfaces between maps, trajectories, weather, constraints and visualization.

A good interface document does not slow down innovation. It protects it. It ensures that creative ideas can be assembled, tested, reviewed and continued by future teams.

For students, learning interface management is one of the best ways to understand real aerospace engineering. Aircraft design is not only about designing parts. It is about making parts work together.

== Internal references ==

* Bee-Plane collaborative project documentation.
* ISO-Plane TRL2 technical and project-management documentation.
* Mini-Bee technical and project-management documentation.
* GPS 4D collaborative project documentation.
* Lesser Open Bee License 1.3.
* Best Practices for Lesser Open Bee License 1.3 Users.
* Best Practices for Engineers on Project Management.
* Best Practices for Collaborative Engineering Deliverables, Bee Projects TRL 1–3.

== License reference ==

''Task achieved under the Lesser Open Bee License 1.3 Chapter 2 Open source – © Coordinator Technoplane SAS.''