1 / 16

Updating Onboard-Databases

Updating Onboard-Databases. (Updates für Onboard-Datenbanken). Author: Christian Grothe. Overview / Agenda. Static Cockpit Data - Trends. More onboard applications use electronically stored (“static”) data Data(bases) integrated in appliances

moswen
Download Presentation

Updating Onboard-Databases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UpdatingOnboard-Databases (Updates für Onboard-Datenbanken) Author: Christian Grothe

  2. Overview / Agenda

  3. Static Cockpit Data - Trends • More onboard applications use electronically stored (“static”) data • Data(bases) integrated in appliances • Trend: integrate all kinds of stored data in one database (server) • Timeliness of data critical • Problem: keeping data up-to-date → Update Solutions Needed!←

  4. Onboard Applications - Examples • Synthetic Vision Systems (SVS) • enhancing situational awareness by displaying the aircraft in its environment: terrain, obstacles, navaids, … • Taxi Positional Awareness • bird’s eye view display: moving map of airport with own aircraft for enhanced situational awareness to avoid “runway incursions” • Flight Management System • allows programming of flight plan to be used by auto pilot, supported by visual representation • standard equipment in every aircraft! • Chart Generation • replace cockpit paper charts (procedures, airport map, …) used by pilots today with dynamically created charts

  5. Aviation Data - Classification • 4 Classes of electronically stored, static “Aviation Data” used in onboard applications • Navigation data • Terrain data • Obstacle data • Airport Mapping data • (Cultural data) • Semi-static or dynamic Data • Weather data • Traffic data • Performance data • Will concentrate on static data

  6. Navigation Data • Information about artificial (man-made, real or virtual) objects used for navigation • Procedures: approach, arrival, departure, missed-approach • Navaids: position, frequencies, types (VOR, NDB, DME, VORTAC, ... • Airports/Heliports: frequencies used, runways, ILS, MSA areas • Airways, Airspaces: special/ restricted usage, … • Storage format: “ARINC424” • old (70s), complex (specification: >350 pages) • defines concepts, structures and dependencies of navigation data • ASCII format • optimized for fast retrieval in FMS

  7. Terrain Data • Model of earth surface • describes “elevation” (deviation from earth ellipsoid) • usually: measured at equidistant posts, distance between posts: “post-spacing” • typical post-spacing values: 30, 3, 1 arcsec (DTED0,1,2) • 2 different models: DSM/DTM (Digital Surface/Terrain Model), with/without vegetation, “canopy”/”bare earth” model • Storage format: DEM (Digital Elevation Model) • “grid file”: binary/ascii elevation values in columns/rows • header information with lat, long, post-spacing, #cols, #rows

  8. Obstacle Data • Information about (“significant”) obstacles for aviation • 3 Types: point obstacle (antenna, building, tree, …), line obstacle (power line, cable, fence, …), polygon obstacles (usually not used) • line obstacle represented as set of posts (line string) • position(s), type, horizontal dimension (diameter) • Storage format: tables or gis • table format: simple, one row per point obstacle or line obstacle post, often as ascii (csv) • gis: as point/line/polygon shapes, attributes added to the shape

  9. Airport Mapping Data • Map of an airport • every (group of) airport element described separately: buildings, runways, taxiways, markings • attributes added to every element: surface type, height, name, … • Storage format: “AMDB” • gis storage format: ESRI shape (shp) files, geometrical shapes (point, line, polygon) with additional attributes (in DBase dbx files)

  10. Acquisition ways for aeronautical data • Data Providers • like Jeppesen, Lido • get data from different sources: publicly available (land surveying office), bought or own surveilling) • verify, process, integrate, tailor data for customers (airlines, aircraft manufacturer) • responsible for quality! • Aeronautical Information Services (AIS) • processes defined by ICAO • every member state publishes AIP and Amendments, Supplements thereto • AIP contains information about national regulations, responsibilities (ATC centers), procedures, airways, etc. • changes become “effective” on special dates (28 day cycle) • temporary or short term changes published in NOTAM (Notice to Airmen)

  11. Board/Ground Data Exchange • Data Medium – manual transport and integration • diskette, cd, dvd, memory cards, … • loaded into the board systems over “data loader” • standard today! • “Gatelink”: WLAN at the terminal • only some airports have gate link • not standardized, isolated application • “Connexion by Boeing”: Broadband Internet over satellite • proprietary solution, operational since 5/04 • only few aircraft equipped (some 30), 5 airlines • Data Links / ATN

  12. Data Links (1) • Only data connection to aircrafts approved and certified by ICAO • Data Link Service Provider (DSPs) like SITA and ARINC offer ground routing of data • ACARS: first data link • starting 70s, meant to be used for AOC messages • automatic messages (through triggers) and manually entered messages possible • protocol: 2.4 kbit/s, character oriented, medium access: stop-n-wait → only short text messages • widely used! channels congested • Benefit of data connection to airplanes realized by industry lately (90s)!

  13. Data Links (2) • VHF Digital Data Link (VDL) • 3 flavors: Mode 2, 3, 4 • different protocols, 19.2/31.5 kbit/s • Mode 2 operational today, transition from ACARS in progress: “ACARS over AVLC (AOA)” • Mode 3 and 4 to come (M3 favored by US, M4 favored by Europe) • Mode S Secondary Surveillance Radar • radar beam used to “interrogate” transponder and send data (4 Mbit/s) • transponder sends surveillance data and “user data” (1 Mbit/s) • main problem: data can be exchanged only when in center of radar spot beam – results in some 100 bit/s • not operational for industry use yet, tests for use by ATC in progress

  14. Data Links (3) • Satcom • Inmarsat (geostationary): 0.6 - 9.6 kbit/s (64kbit/s), does not cover polar regions • Iridium (LEO): 2.4 kbit/s, equipment much cheaper • data transfer expensive, therefore used only in oceanic regions • HF Data Link (HFDL) • offered only by ARINC, 2 to 30 MHz, long range • low transfer rates: 0.3 – 1.8 kbit/s • competition for Satcom, used primarily on polar routes • needs special antennas, not widely used

  15. Aeronautical Telecommunication Network (ATN) • Main Problem of Data Links: varying equipage • Idea: one network, integrating different data link subnetworks interoperably • ATN initiative started in early 90s by ICAO, RTCA, ATA, IATA, AEEC • Network based on X.25 concepts • 4 main elements • network mobility: location transparency • QoS: specify costs, transfer rate, connection, … • data compression: accounting for data links’ low bandwidth • standardization of services for ATS applications • Problem with implementation: nobody wants to do the first step

  16. Update Procedures • Based on operational constraints, safety issues, certification problems and feasibility limitation, different design options are possible • Full Update or Incremental Update? • Full Update (better: Replacement) very simple, impact on onboard server implementation: read-only – state as of today • Incremental Update: Much smaller update packages (for online submission), but have to care for lost updates, integrity checking, … • Data Delivery Options • initiated by provider, when new data is available: push • initiated by operator, when up-to-date data is needed: pull • periodical, without trigger

More Related