LHG:DAS Interface: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
← Older edit
VisualWikitext
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,381 edits
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,381 edits
No edit summary
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
DAS is a Lufthansa tool which holds flight information.
DAS is a Lufthansa tool which holds flight information. It is required for these i[[LHG:Interface dependent use cases|nterface dependent use cases]] in SARA and Portals,


== Contained data ==
== Usecase ==
We interested from DAS system with this information stream
Lufthansa MOC team needs to be notified by our SARA system as fast as possible on certain changes relevant to PAX. Currently the team is checking on a regular (daily) basis if any relevant flights have changed which transport passengers. Relevant changes are:


==== Long Term Flight Plan ====
* changes on aircraft
This holds the regularly planned flights:
* changes on aircraft type
* delays
* status change (on plan / delayed / cancelled )


* FLIGHT NUMBER
So we would like to listen to DAS over Kafka to receive all changes and select from the stream messages, which affect passengers with special assistance requests being filed.
* FROM
* TO
* LOCAL DEPARTURE TIME
* LOCAL ARRIVAL TIME
* Planned flight duration
* Planned craft type


==== Dispatch data ====
== Implementation ==
This holds for each planned flight
This is a two components concept


* status (on plan / delayed / cancelled )
====== Bridge server digital (residing inside LH intranet) ======
* delay time
On the Bridge Server Digital:
* Operating craft
* We implement an indexed local data cache (LDC controller) which consists of a set of files. For each day, we have one file. The [[Dev:LHG DAS-Interface Technical description|DAS-Files adhere to this structure]].
** type (e.g. Boing 747-8)
* We implement a proprietary service which constantly receives update messages from the KAFKA Topic and stores it in local files.
** tail code
* We implement a Shared Data Cache controller (indexed: per day), which shares the DAS-Files to any digital (e.g. LH MOC Digital) where an adequate trust relation exists
* Required trust on sending side has TCI ''Share-DAS-information''.


== Use-Cases with SARA ==
====== LH Operation Center (MOC) digital ======
On the MOC side the


====== Service availability check for SAR (before confirmation to PAX) ======
* DAS-Files containing the LH rotation planning are received through the SDC controller, if the trust relation on receiving side has ''Accept-DAS-information''
When a request comes in, the team needs to check if planes operating the passengers itineraray's segments do support the requested services. For this, SARA should show the plane type (planned or if available operating). This allows the team to immediately see and SARA to detect incompatibilities before confirming the service to the PAX.


Required data for this use case:
* MOC digital builds a local data cache (LDC) with list of relevant flights (departure date, flight number, planned departure data) which bear future flights with passengers with SAR-Requests on it
 
* A background service detects relevant changes to the flight planning, whenever the shared cache (rotation planning) or the local cache (with flights with SAR on them) is updated and triggers:
* Flight plan with planned craft type
** an update of the service delivery tree
* (optionally if already available) operating craft type
** (optionally) a task creation for MOC team
 
* Relevant changes are:
====== Detection of rotational changes (pre-flight, after confirmation to PAX) ======
** Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)
Operational changes can have heavy impact on a PAX journey, especially when it comes to mountable devices (stretcher, wenol) or extra-seats. Mountable devices may not me mounted directly before the flight, but eventually already one flight before. If the plane changes for a PAX, this might mean that the mounted device might not be available for the PAX. So SARA needs to notify MOC if any rotational change has occured, which holds a passenger with a SAR request bearing one of these services.
** Departure information change
 
** Passenger journey change
Example: PAX is on a flight EWR to MUC, OUtbound stretcher mouting in MUC happende on plane with tailcode LHFBG. Not the plane had to return to MUC and instead operations team decided that the plane with tailcode LHODB will operate the flight EWR to MUC. This means that not stretcher is available for the passenger. This needs ad-hoc management action with MOC. Purpose of SARA is to notify the MOC team immediately before any of these changes immediately, so that they can react, e.g. with rebooking of passenger.
 
Required data for this use case:
 
* Flight plan with planned craft type
* operating craft type
 
====== Services availability check for general iquiries {{Yellow-Tag|YellowText=Scheduled for later phase}} ======
For general inquiries MOC team wants to check, which flights are generally available. For each of these flights they need to check the planned or operating craft type and will from this see for which of the generally available flights, this service is supported.
 
Required data for this use case:
 
* Flight plan with planned craft type
* (optionally if already available) operating craft type
 
== Planned interface approach ==
KORDEUS is building a KAFKAA interface, which subscribes to a '''"MOC/SARA" KAFKA Topic'''. Through this it which recieves two types of messages:
 
====== Flight plan updates ======
This information containing a list of all flights planned and scheduled for the next 6 months? Contained information:
 
* FLIGHT NUMBER
* FROM
* TO
* LOCAL DEPARTURE TIME
* LOCAL ARRIVAL TIME
* Planned flight duration
* Planned craft type
* Repetition pattern (weekdays, monthly, exact dates)
 
====== Operations updates ======
This information containing all operations planning items (typically 1-2 weeks ahead of the flight), but also for adhoc travel informaiton
 
* Departure date
* Flight number
* Planned craft type
* Tailcode
* status (on plan / delayed / cancelled )
* delay time
 
== Solution ==
From this information SARA builds a local application cache, which holds for each planned flight within the upcoming 3 months a status, which is used within SARA for MOC for:
 
* Display information for SAR-Request handling/management
* Creating tasks - in case of rotation changes


== See also ==
== See also ==


* [[LHG:SARA Project]]
* [[LHG:SARA Project]]
* [[LHG:Interface dependent use cases]]

Latest revision as of 12:43, 23 December 2025

DAS is a Lufthansa tool which holds flight information. It is required for these interface dependent use cases in SARA and Portals,

Usecase

Lufthansa MOC team needs to be notified by our SARA system as fast as possible on certain changes relevant to PAX. Currently the team is checking on a regular (daily) basis if any relevant flights have changed which transport passengers. Relevant changes are:

  • changes on aircraft
  • changes on aircraft type
  • delays
  • status change (on plan / delayed / cancelled )

So we would like to listen to DAS over Kafka to receive all changes and select from the stream messages, which affect passengers with special assistance requests being filed.

Implementation

This is a two components concept

Bridge server digital (residing inside LH intranet)

On the Bridge Server Digital:

  • We implement an indexed local data cache (LDC controller) which consists of a set of files. For each day, we have one file. The DAS-Files adhere to this structure.
  • We implement a proprietary service which constantly receives update messages from the KAFKA Topic and stores it in local files.
  • We implement a Shared Data Cache controller (indexed: per day), which shares the DAS-Files to any digital (e.g. LH MOC Digital) where an adequate trust relation exists
  • Required trust on sending side has TCI Share-DAS-information.
LH Operation Center (MOC) digital

On the MOC side the

  • DAS-Files containing the LH rotation planning are received through the SDC controller, if the trust relation on receiving side has Accept-DAS-information
  • MOC digital builds a local data cache (LDC) with list of relevant flights (departure date, flight number, planned departure data) which bear future flights with passengers with SAR-Requests on it
  • A background service detects relevant changes to the flight planning, whenever the shared cache (rotation planning) or the local cache (with flights with SAR on them) is updated and triggers:
    • an update of the service delivery tree
    • (optionally) a task creation for MOC team
  • Relevant changes are:
    • Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)
    • Departure information change
    • Passenger journey change

See also

Retrieved from "https://wiki.kordeus.com/index.php?title=LHG:DAS_Interface&oldid=2931"