uwe-salomon
commented
3 months ago In a first discussion with Patrick, the following requirements for the (business/first class) seat types were found:
- Publish seat system failures for maintenance
- Publish seat operating status, e.g. ok, failed, maintenance mode, for cabin crew and maintenance
- Publish seat motion locked / TTL locked status for crew
- Publish TTL readiness indication for crew
- Publish seat position for crew to indicate guest may be sleeping [optional]
- Receive command to move (all seats) to cleaning position from crew
- Interface with IFE to control seat position; Patrick said that this interface is custom for a particular seat type / IFE combination today
- Publish data for creating usage statistics for airline and manufacturer, e.g. an unused because badly defined relax position, e.g. how much is moving used
- Associate data with unique device identifier, e.g. manufacturer, part number, serial number; this could be used throughout the CSMIM network
Remarks:
- Seat types have different sets of positions, plus there are intermediate positions
- Topic structure should reflect seats (row, column) not physical controllers that might control multiple seats at once
- Undecided whether topic should put row and column together (3A) or separate (3/A)
- Failure reporting could be moved into a specific interface that is used throughout the CSMIM network
- Unclear whether there is a need for a generic "Device" supertype, because its functionality seems so generic that it is either empty or full of optional resources
- Undecided whether static data (manufacturer, part number, serial) are better modeled as resources or as attributes
The issue is to define types for seats within the cabin. Seats could be all types of seats from first call to economy.