Patent Application
20120013252
Washlights are used to provide lighting accents generally via indirect lighting (i.e., an area is illuminated primarily by light from the illumination source that is optimally a smooth and even wash of light that is hidden from direct line of sight by passengers and generally reflected off of another surface). For vehicles in general, and specifically here for aircraft, washlights can be used to create various moods and scenes, particularly when colored lighting is used.
Advances in light emitting diode (LED) technology has made them an ideal source of light where low-powered lighting solutions are desirable, which is particularly true in aircraft in which power availability is limited. However, with known systems, a degree of sophistication is lacking with regard to the full range of control that is possible with the use of LEDs and light sources having similar properties.
A modular lighting system is thus provided in which modules and module groups comprising banks of LEDs, which may be of multiple colors, to create certain lighting scenarios and mood effects. The modules or module groups are intelligent in that they contain control circuitry to enable efficient control of the lighting.
Ideally, this modular lighting system can be designed to take advantage of existing lighting structures, such as incandescent bulbs or fluorescent lamp and/or fixtures so that the older systems can be replaced or retrofitted with minimal disruption and effort.
The intelligent light module group has: one or more light modules, each of which comprises a plurality of discrete illumination sources; a power supply; and an intelligent module group controller comprising: a) circuitry that controls the illumination levels of the illumination sources; and b) an interface for receiving and sending information and providing power. The system may also further comprises a system controller that comprises: a) an attendant control panel serving as a user interface; and b) a system controller interface that is connected to the module group controller interface.
Various embodiments of the invention relate to an illumination system and method for illuminating an interior of a vehicle. Accordingly, a method is provided for illuminating an interior of a vehicle with a modular area illumination system, the modular area illumination system comprising: a system controller; and a plurality of an intelligent light module groups, each comprising: one or more light modules, each of which comprises a plurality of discrete illumination sources; a power supply and power interface; and an intelligent module group controller comprising: a) circuitry that controls the illumination levels of the illumination sources; and b) an interface for receiving information; the method comprising: initializing each of the module groups to assign a unique address to respective module groups; sending a command, by the system controller, directly or indirectly, to each module group, the command being associated with a color and illumination value; and receiving the command, by a module group, and adjusting a color and illumination of the illumination sources to the associated color as well as turn on/off or transition times from one scene or mode to another; performing self-checks and providing BIT/BITE information.
An associated modular area illumination system, is also provided, the modular area illumination system comprising: a system controller; and a plurality of an intelligent light module groups, each comprising: one or more light modules, each of which comprises a plurality of discrete illumination sources; a power supply; and an intelligent module group controller comprising: a) circuitry that controls the illumination levels of the illumination sources; and b) an interface for receiving information; an initialization module of the system controller for: beginning the assignment of a unique address to respective module groups; and sending a command, directly or indirectly, to each module group, the command being associated with a color and illumination value; and an initialization module of the module group controller for receiving the command and adjusting a color and illumination of the illumination sources to the associated color.
The invention is describe below with reference to the drawings that illustrate various embodiments of the invention.
A modular lighting system is provided in which the modules or module groups contain an intelligent control.
Within each of these regions 20, one or more lighting module groups 60 may be provided. These module groups 60 may be fashioned as line replaceable units (LRUs) to enable quick assembly, maintenance, and replacement. For example, one module group 60 could be for the main cabin bin lighting for rows 10-15. As used herein, the term LRU can be considered interchangeable with the term module group 60.
The aircraft lighting system 10 further comprises a system controller 30 that can use, e.g., an ACP 40 as the primary user interface for attendants controlling the lighting during a flight (including on-ground parts of a flight), as well as for maintenance. As used herein, generally, the terms system controller 30 and the ACP 40 are used interchangeably, although the ACP 40 should be understood to be the primary user interface for the system controller 30.
The LED modules in the system are designed to be interconnected with one another into module groups. The lighting module groups 60 each comprise a power supply 70 that converts the aircraft power into a power usable by the module group 80, and may comprise a filter 80 for filtering out harmful noise and other signals. Each module group preferably comprises a module group controller 90 that can intelligently handle high-level instructions from the system controller 30 and possibly provide useful information back to the system controller 30. An aircraft connector interface 50 is provided between the power supply 70 and the controller 90.
The lighting module group 60 may comprise one or more lighting modules 110 that each, in turn, comprise a plurality of LEDs 130 that may be organized in LED groups 120. Note that an individual LED 130 could belong to more than one group 120. For example, an LED 130 could be arranged according to one group based on the manufacturer, and could be arranged in another group based on its color, intensity, forward voltage Vf, forward current If, LED bin, color rendering index (CRI), and other possible parameters.
Note that when the lighting module group 60 comprises a single lighting module 110, the characteristics (such as power supply 70, filter 80, and controller 90) can be associated with the module 110 itself. In other words, the lighting module group 60 and lighting module 110 could be construed as the same thing when there is only a single module 110 in the group 60.
Each module 110 can be designed to comprise one or more of the following: a) control circuitry 90 for controlling the module and possibly other attached slave modules 110′ in a group 60; b) power supply circuitry 70 to enable an LED washlight to function off of, e.g., a 115 VAC, 400 HZ power source. The power supply 70 can, e.g., receive 115 VAC, 400 Hz in and convert it to low voltage AC and DC, including 28 VDC, 12 VDC, 5 VDC, or whatever DC voltage is typically necessary for LEDs and electronics to operate. The power supply 70 design is preferably a switching power supply, but could also be a linear or other topology with approximately a 75%-85% efficiency or more and receive approximately 7.5-15 W in and provide 5.7-11.4 W out to the LED, microcontroller and other electronics load; and c:) filtering circuitry 80 to filter incoming power to the modules and ensure that no problematic harmonic emissions, spikes or other undesirable power conditions are introduced back onto the aircraft power bus.
The LEDs 130 within a module can possibly be controlled individually, within specific groupings of LEDs 120 within a module, or collectively (all LEDs in a module). The groupings 120 can comprise arbitrary numbers of LEDs, or can be grouped according to area zones, color, LED characteristics, or other schemes.
As noted above, the modules 110 may be collected together into module groups 60, e.g., three modules 110 to a module group 60.
Although
As is illustrated in
Configuration A illustrates a module group 60 in which each module 110 comprises a power supply 70, a filter 80, and a controller 90. However, in Configuration B, it can be seen that the first module 110 only comprises a filter, whereas the second module 110 comprises the power supply 70 and control, and finally, the third module 110 does not comprise a power supply 70, filter 80, or controller 90. In this illustration, the third module 110 is a dummy that just accepts the power and control from a different module in the group.
For a module group 60, there can be one power supply 70 per unit or two power supplies 70 per unit preferably at opposite ends of the device and also preferably fitting within a washlight extrusion or within a bracket area at each end of the washlight. If more power is needed, the power supply 70 can also extend into a bracket area that connects lighting units together into an assembly, which can increase the power output capability.
The LEDs 130 can be fed from one or both power supplies 70 either in a linear array, series and parallel configurations, individual or Groups of LEDs, alternating LEDs 130 or in a U-shaped array or any combination thereof. These configurations perform slighting differently when the LEDs 130 are powered up or if one string of LEDs goes out.
The two linear strip array approach also allows for light levels to be increased incrementally and independently which should help extend the life of the device because each power supply 70 could alternate their operation thus allowing each power supply 70 to run at lower than maximum levels and/or be off for periods of time to allow the power supply 70 to cool off. The power to a specific LED 130 can be controlled via modifying the voltage/current level to the LED or by a scheme such as pulse-width modulation, LED driver or control circuitry, etc.
Also, additional external power supplies 70 that are preferably located within the bracket area can be added and controlled in the same manner above thus increasing the overall power output and life of the device.
As noted above, the modules 110 themselves or module groups 60 can collectively be controlled by a master or system controller 30. Such a master controller 30 can permit operation of the modules 110 or module groups 60 at a much higher functional level than has previously been possible.
The modules 110 are theoretically continuously adjustable to colors within the CIE 1931 chromaticity diagram by varying the power to the different LEDs (red, blue, green, white, warm white, yellow, amber), and commands could be directed toward the modules 110 or any grouping of modules that allow for any color definable by X, Y coordinates in the CIE 1931 color space; however, without proper calibration, the LEDs' display of a color would only be approximate, although a color sensor that detects color and phototransistor that detects light output could be used and proper color and luminosity could be maintained via a feedback mechanism using the sensor, phototransistor, etc.
However, it is preferable if only a discrete set of colors are allowed that represent points on the CIE 1931 chromaticity diagram, primarily to aid in the calibration and use of the LEDs to ensure color consistency. A set of predefined color points selected from within the CIE 1931 color space can be defined by an end user.
This set of predefined color points should be in common with all modules within a given system, so that a module in any part of the vehicle would display a “Color Point 5 (CP5)” consistently, as would a brand new module brought in to replace an older module. In a preferred embodiment, the set of color points is limited to sixty-four colors, although larger or smaller sets of color points can be used. A larger color set would provide more flexibility, but would also require a more extensive calibration procedure, since additional color points would have to be calibrated. A smaller color set would reduce flexibility, but require less effort in calibrating. Grouping of target color points that may be in close proximity and ones with similar LED characteristics and behavior on the CIE chart or tighter LED binning allows for groups or some target color points to be calibrated together and not necessarily individually, and hence only one CP within a group of, e.g., eight CPs need be calibrated, and the other seven CPs can be calibrated automatically with the same adjustments made to the primary CP.
In a preferred embodiment, the modules 110 comprise a table containing records for each color point. Associated with each record is an indication of the drive power for each colored LED necessary in order to reach the color point, when a luminosity value is applied, and when corrected according to the calibration values discussed below. A drive power could be represented, e.g., in a form of a percentage of duty cycle of a signal sent to each of the groups of colors in a module. For example, CP5 at a specified luminosity could be associated with a red duty cycle of 0.35, a blue duty cycle of 0.6, a green duty cycle of 0.2, and a white duty cycle of 0.15. The power to drive the LEDs in the module would be adjusted based on values obtained from the calibration tables also associated with the module 110, and include compensation values for current temperature as well as age of the LED. In an embodiment, messages that contain a desired color point and/or luminosity value could be sent to the module (e.g., “change to CP3 at luminosity value 50”), and the module would respond by changing to the color values associated with the requested color point and luminosity, again corrected by the calibration, temperature, and aging values.
A very high level of control involves defining various “scenes” that dictate certain lighting characteristics that can be applied, e.g., airplane-wide. The use of these high level scenes can greatly simplify complex lighting control, and can permit, e.g., a flight attendant, to select a scene from a few basic scenes to create a particular lighting pattern, using the ACP 40 that is connected to the system/main controller 30.
For example, a scene designated “entry/exit” or “cleaning/maintenance” might designate a maximum level of white lighting (e.g., 5000 Kelvin), whereas a scene of “daylight mid-flight” might designate a moderate level of lighting with a cooler color temperature (e.g., 3000 Kelvin) having more of a yellow component. A scene of “night-time sleeping” might designate a very dim blue lighting. In this way, specific predefined scenes can be used to easily control the cabin lighting. It is possible to provide an override that would let the specific level for each color group be manipulated from a user interface of the main control device.
In a preferred embodiment, the scenes are defined solely in terms of the predefined set of color points, although the same color points would not have to be used for every light throughout the cabin. Using the example from the immediately preceding paragraph, CP1 might define pure white lighting, and CP2 might define a yellow color, and CP3 might define a sky blue. The scene “entry/exit” might have all module groups set at CP1 at maximum luminosity, whereas the scene “daylight mid-flight” might have the over wing exit lighting set to CP1 at a first luminosity value, whereas the bin lighting might be set to CP3 at a second luminosity value.
In one preferred embodiment, messages can be sent to the modules 110 in terms of the high-level predefined scenes (e.g., “change to the entry/exit scene”). The module 110 could then check a table located within the module to see that the entry/exit scene corresponds to CP3 at luminosity value 1 and change to the appropriate color. As noted above, however, each module 110 or module group might have a different color point associated with a scene, so the scene command “change to the entry/exit scene” for a module 110 in the over-wing exit might be associated with a different color and luminosity value than a module 110 associated with the general cabin or bin lighting.
Preferably, a predefined set of standard scenes is loaded into the modules 110, and the flight attendants set a desired scene by selecting a scene from, e.g., a list on a display of the ACP. However, it is also possible that custom scenes (e.g., “custom scene 1”) are defined using the ACP or other equipment and software. The relevant color points for this scene can be defined and downloaded to each module 110 or module grouping.
Although changing from one scene to another is preferably manually performed by a flight attendant via the ACP, it is also possible to provide for an automated transition to various scenes as well. The automated system could be implemented on the system controller 30 and make the transitions based on a particular time (e.g., “at 8:30 pm” or “20 minutes after the start of flight” or “20 minutes after the previous transition”), or based on a particular flight phase (“when cruising altitude is reached”—this would require some sort of interface with the flight system), or other event (e.g., detection of air turbulence—this would require a further interface with sensors/detectors/other aircraft systems).
As noted above, the controller 30 itself may have corrective algorithms that permit precise adjustment of the LEDs 130 and that could, e.g., compensate for aging LEDs 130, color shifts, light output, etc., over time. Similarly, the corrective algorithms could reside in the module groups 60 or modules 110 themselves.
Furthermore, when transitioning from one scene, or even color/level setting, specific algorithms can be implemented to effect a smooth transition—which is not necessarily a linear adjustment of each respective color but rather could be logarithmic, discrete steps, etc. Thus, to adjust from 100% brightness to 20% brightness from white to blue, a linear adjustment might introduce an undesirable red component in the transition. Thus, in one embodiment, specific look-up tables (LUTs) can be provided that are used by the controlling processor(s) (system controller 30, and/or group/module controller 90) containing the necessary brightness values for properly adjusting during the transition. The control may be effected using software algorithms specifically designed for creating scenes and controlling the transitions.
Alternately, or additionally, the transition from one scene to another could be predefined in terms of a series of color points that are to be used. In other words, one could define a transition of a dinner scene at CP2 to a nighttime scene at CP9 to transition through CP4 and CP8 to arrive at CP9.
Furthermore, given certain restrictions on the use of power (total power, real power, and reactive power), it may be desirable to provide the control circuitry (in the system 30 and or group/module controller 90) with the ability to limit the overall power consumption to be within some specified limit, and this limit could vary depending upon the situation of the aircraft. This permits precise control of the system, even though the collective power consumption of the system might exceed predefined limits.
For example, the lighting system may, when fully engaged in its brightest configuration, consume 2000 W. However, there may be a limit imposed on power used in flight of 1000 W, whereas it is permissible to use the full 2000 W when on the ground and parked. In this scenario, the controller could ensure that no more than 1000 W is delivered to the lighting system when the plane is in the air.
One way to achieve this is to have a database of the power consumption characteristics for each module 110 associated with the master control 30. In the event that a request is received that would exceed the permissible values, the master control 30 could appropriately reduce the light levels to keep the system under the necessary limits. For example, if a flight attendant inadvertently selected the scene “entry/exit” with its maximum lighting requirement of 2000 W, the master controller could detect that this is improper and limit the levels to 50% or less so that the 1000 W cap is maintained. This also applies for non-unity power factor power supplies and limit the total power in VA including real power in Watts and reactive power in VARs.
Scene developer's software can be provided to ensure that no scene or mode will exceed a fixed or variable total power consumption for the entire lighting system 10, a given application type, LRU or device. The software can automatically regulate the wattage or VA load and notify the user or programmer, etc., that the limit is being approached, has been met, or has been exceeded, and once met will not allow anymore devices to be added.
Additionally, the controller 30 can have another option to allow for random and/or identifiable priorities to be set for lighting applications, LRU's or devices so that a maximum power will not be exceeded by reducing the total power to selected applications, thus automatically scaling back the light output on lower priority applications while allowing more to others.
This may be linear, logarithmic, or discrete, or employ more complex relationships and algorithms and weighting factors to each load type. This is preferably done automatically without user intervention and displays and memory tables can be used to show and store lookup values respectively for current draw, wattage or VA consumption, priority settings, etc., and this information along with the final configuration can be displayed in the manufacturing equipment, in field flight attendant panels, etc. This software may be stored in a master controller 30 or LCD display of the ACP 40 and information about individual lighting loads as requirements can also be sent (or preloaded) and stored in the lighting device (module group 60 and/or modules 110) itself, as required.
Summarizing and providing more detail, an aircraft lighting system 10 may incorporate numerous modules (modules 110 or groups 60), each comprising a plurality of LEDs 130. In this system 10, the following attributes can be provided: lights and groupings at any level (LED 130, LED group 120, module 110, module group 60, region 20, and whole system 10) can be, but do not need to be, individually addressable.
Advantageously, a hierarchy of “groups” or “zones” of lights and modules are provided in a manner that is easier to control and that allow the lights to function together. The system 10 can provide dynamic scenes that change over time, and these scenes can be simply controlled via control logic 30 associated with the ACP 40.
In one embodiment, the lighting units (either modules 110 or module groups 60) as line-replaceable units (LRUs) can be shipped from the factory with pre-configured scene information already stored. A base set of scenes, such as those described above, could be programmed into the modules 110 or groups 60 so that they can be easily integrated into an existing system. The system 10 can also comprise a scene creation tool that permits a scene developer to design their own scenes and transitions between scenes. This could also be integrated with the power management tool to help ensure that maximum permitted power is not exceeded, or to help reduce power consumption costs. Additionally, in one embodiment, multiple intensities for the same scene can be designated. For example, the mid-flight scene could be provided in a High/Medium/Low/Night/Off setting.
In a preferred embodiment, some system intelligence can be placed within a scene generation tool of the group 60 controller 90. In such a design, the lighting LRU 60 firmware in the controller 90 is simple, and the same. The system 10 can be designed to prohibit updating of the LRU 60 electrically erasable (E2) memory in the field (under the design guide that devices returned to the factory should be in the same configuration they were when they left). In this scenario, controller communications are minimized, and a smaller bandwidth can be realized.
An exemplary LRU E2 memory layout of scene data is provided below: (for the purpose of this illustration: High=0, Med=1, Low=2, Night=3, and Off (not shown)). This assumes, of course, that four intensity settings (five, if Off is counted) will be provided for each scene (thus, all scenes will actually have four rows worth of data each in the memory layout), although this number could vary. For example, there could be ten or more different dim settings, and an intensity level setting as low as, e.g., 0.01% could be provided.
Unused scenes and/or intensity variations can simply have 0's for all light values (ensuring that they are off for that selection). Not all columns will be used by all light types, but all will be present on all lighting unit LRU's 60. The lighting LRU 60 type is preferably written to E2 memory during a final calibration phase (along with the calibration data), when the unit is about to leave the production center. A serial number of the unit can be provided, and its characteristics can be associated and stored for later reference. The lighting LRU firmware can use the light type in its E2 memory in order to determine which values to use.
The following table illustrates an exemplary arrangement for storing a scene table.
Utilizing this philosophy, the entire scene table can occupy approximately 708 bytes of E2 memory for 12 scenes. Calibration data may be stored in a similar fashion (as shown by the sample table below).
Thus there can be one bias table entry (calibration offsets) for each intensity group. For the example shown of four intensities, the entire table will have four rows (occupy 48 bytes). If required, the bias table could be expanded so that every built-in scene has its own bias entry.
The preferred operation is that on LRU 60 power up, the firmware will load with a power-up default state or, after some predefined amount of time, such as 30 seconds, with a no-communications default state. Both of these default states can be set at any time, but preferably is set at calibration. The LRU 60 attempts to establish communications over a communication link, such as RS-485 with the ACP 40, and the failure to establish communication with the ACP 40 within the predefined time interval, as noted above, results in the no-communications default scene being activated. This provides a failsafe mode in the event that the ACP 40 is broken, missing, or non-functional, and will allow there to be light on board the aircraft. An extra scene can be provided as the “failsafe” with little impact to memory requirements. Upon receipt of a valid command from the ACP 40 to change scene selection or intensity, the appropriate table entries can be loaded into RAM by the firmware, and the scene transitioning will start to occur.
Under this scheme, the ACP 40 does not need to “know” anything related to the default “canned scenes”. It merely sends a broadcast message on all of its communication (e.g., RS-485) ports to change to scene #X, with intensity level Y), to elements at the regional 20, module group 60, or module 120 level. A one-time correlation can be made in the ACP 40 that, e.g., scene 1=Boarding/Disembark, 2=Safety Video, 3=Taxi/Takeoff/Ascent, etc., so that the display activation sends out the correct scene number to correspond to the data contained in the internal tables. This simple scheme satisfies all of the requirements for a baseline system.
Prior to the operation of the lighting system, an initialization must be performed. In the initialization operation, (preferably performed in a maintenance mode), the system controller 30 polls all of the light boards to see what boards are available and to perform an addressing of all available boards.
In a preferred embodiment, the controller 30 runs a sequence, sending a message to the first module 110.1 in the system indicating, “you are module 1”, then the first module 110.1 will send a message “you are module 2” to the second module 110.2, and this will be repeated for each and every module in the system, or at least for the modules in a group connected to a particular port of the system controller 30. In an embodiment, there are two lines to the light modules—the first is a token line by which a token is passed giving a particular module the right to transmit and permitting a module 110 to know that it is the one being spoken to over the RS-485 data line. The second line is the actual RS-485 data line permitting the transmission of data. The system controller 30 initiates the token line, telling the first light that it is the first address. Although all modules “hear” the message, “you are module 1” sent via the RS-485, only the first module sees that its token line is active, and therefore that the message is meant for it. The other modules, seeing that their token lines are inactive, simply ignore the message. The light module acknowledges that it received the addressing message successfully and responds back to the system controller 30 “I've been addressed successfully”. The system controller then releases the token line, and the first light asserts its token line to the second light, and performs the same process.
This initialization can be done once per installation, once per power down/maintenance mode or at any other frequency that the plane maintenance crew determines it needs to be done.
Once all of the LRUs or modules have been properly addressed, the system controller 30 can communicate directly to the lights or directly to the group of lights, depending on the zone.
The system controller 30 then divides the plane up into zones, so each light board will be associated with a zone, depending on the light. Then scene content information is sent down, which is really the mapping of the system controller 30 predefined color points to messages sent to the controllers of the light boards. The system controller 30 has, e.g., a button that, when pressed, will select a particular scene.
Upon system power up, each module group 60 can wait for 30 seconds to receive a Scene Selection Message. If none is received within that time period, the module group 60 should automatically transition to 100% white light or some other default setting.
As previously stated, the ACP 40 will not have to do anything special for an “out of the box” system 10. It can merely broadcast and repeat (at predetermined intervals) the current scene number and intensity value. If a particular light type does not participate in that scene, its table entries will all be 0, and those lights will remain off or in a default or prior state.
The protocol can be configured to allow for BIT/BITE, LRU Grouping or Zones, Custom Scenes, and Maintenance Modes. The BIT/BITE sequence is rather simplistic—it is a request for address status, and a reply. If no reply is received, the fault is logged/displayed etc. Grouping or Zones preferably occur from the ACP 40.
A mechanism may be provided to tell each addressed LRU 60, 110 what group it belongs to (e.g., kept in RAM in the lighting LRU 60, 110). This preferably is resent by the ACP 40 at each system power up and on change (assuming the ACP 40 allows for dynamic moving of zones). The messages sent from the ACP 40 to the lighting LRUs 60, 110 can then incorporate the group number for which the scene/intensity change is directed. Only lighting LRUs 60, 110 that have been configured to be a member of that group or zone, will actually respond to the request for scene change.
In a preferred embodiment, the minimum packet size is 6 bytes, and the maximum packet size is 256 bytes
Each scene change initiated at the ACP 40 can result in a notification message being broadcast to each LRU 60, 110 three times, spaced a predefined number of milliseconds apart. The ACP 40 can debounce scene selections (consecutive button presses) for, e.g., predefined number of milliseconds. The ACP 40 can periodically re-broadcast the current scene selection at predefined intervals.
A group value of “ALL” may also be included to force all lighting units when zones are employed. For the custom scene portion, the ACP 40 will once again need to be involved, since it would be undesirable to remove the lighting units and return them to the factory for addition of new scenes.
Basically, when the custom scene is selected, the ACP 40 can use a message to send the custom intensity values to the lighting LRUs 60, 110. When the lighting LRUs 60, 110 receive these commands, they then place the data into RAM and begin the scene transition. Custom scenes do not have to have any bias or calibration applied to them, since they may not have been developed at the production facility and calibrated for uniformity. Maintenance modes can be provided as well.
A PC-based scene generation tool can be used as the brains of the system, and can incorporate any of the compensation equations for temperature and intensity variations. It is preferably the place to perform the calibration of LRU's as they leave the factory, since it can easily compare a database of expected values to measured ones, and calculate the necessary biases to achieve the desired results. It can also be used to limit system physical temperature and current draw. The tables that this tool may produce can have all of these factors taken into consideration, and may be what is eventually stored in the individual lighting LRUs 60, 110.
As noted above, the general cabin lighting system 10 is used to illuminate the interior cabin of the aircraft. The system 10 may comprise two main parts, the lighting units (grouped 60 or modules 110) and the ACP 40. The ACP 40 may be used as the main interface point for cabin attendants and maintenance personnel. It allows input from users to execute the various cabin lighting scenarios inside the aircraft cabin. The lighting units 60, 110 are the physical units installed throughout the aircraft which are used to illuminate the aircraft cabin to the lighting scenarios selected.
The following description of different communication functions is split into four sections: Normal Operation, Addressing Operation, Bit/Bite Operation and other Misc Operations that may occur (loss of communications, decompression, etc.).
Note that certain lighting units behave identically to the another family of washlights. For example, the 9250-XXX family of washlights is virtually identical to the 9200 family of washlights except for the additional white LEDs that are powered and controlled by a separate dedicated 6 VDC emergency power line which is ideally, but not necessarily, galvanically isolated from the 115 VAC aircraft power source and other power within the LRU.
The lighting LRUs receive the command and begin to transition to the color/intensity received 5218. A rebroadcast for all messages for scene selected 5220 may be performed, and the scene transmission may then be completed 5220 once the necessary rebroadcasting is complete. The ACP410 and associated controller 30 can pass information to the LRUs 60, 110 at a very basic level (brightness level, color information, if possible) to the addresses, e.g., of each individual LED 130. It could also send information to LED groups 120. At a higher level, the information regarding which scene should be activated and be provided as well.
In a preferred embodiment, the communication to and between groups 60, modules 110, the system controller 30, etc., can be done via an RS-485 multi-drop bus, which can handle up to 255 devices and at a rate of 115200 bps. An RS-485-like standard (that, e.g., does not follow voltage differential aspects) could also be utilized. Other communications schemes, including wired (e.g., twisted pair, coax, fiber optic), and wireless (e.g., Bluetooth and Wi-Fi) could also be used. The messages transmitted can include those related to address assignment of the modules, the setting of zones, scene selection, configuration and diagnostic inquires and tests, predefined, and custom scenes.
Communications can be done in the form of commands. An exemplary command is provided below.
As noted above, each lighting unit may incorporate an address. This address helps to identify the location of the lighting unit in the aircraft. Using a lighting layout of passenger accommodation (LOPA), an individual could determine the exact position of the light in the aircraft. Addressing each light makes the system capable of handling multiple zones of lighting, and also allows the systems to do built-in test equipment (BITE) testing to locate faulty LRUs.
The ACP 40 and associated controller 30 can control addressing of the washlights. The ACP 40 can use a Token communications line in addition to the RS485 line to help address the washlights. Each Washlight LRU may have an RS485 transceiver, Token-In, and Token-Out Lines.
The Token Lines may be used to identify which washlight is currently being addressed. If a washlight's Token-In line is active, then the washlight is currently being addressed and any Address Input Messages are intended solely for that device. If the washlight receives the address input message it can acknowledge the receipt of an address with an Address ACK Message. This signifies that addressing is complete for the device and it is time to move on to the next device. Next, the ACP 40 can pass the token by sending a Pass Token Command which will allow the next washlight in the column to be addressed. Once this is received, the currently addressed washlight will set its Token-Out line active so that the next sequential washlight can be addressed. In conjunction, the previous addressed device will set its Token-Out line inactive to complete addressing operations for the currently addressed unit.
The ACP 40 with control 30 controls when BIT/BITE is initiated. The ACP can use the RS485 line to help poll each washlight in the system to determine if the washlight is still active. In addition to polling each device the ACP can send out a lamp test message that will turn on each one of the LEDs on each LRU so a visual check may also be performed.
A number of miscellaneous operations may also be provided by the system 10.
A checksum calculation is provided to help insure the integrity of the transmitted data. The checksum calculation may be a one byte XOR checksum of all the bytes including the SOT byte to the last byte before the checksum value. The checksum has a XOR PRESET of 0x55. After the checksum calculation is completed the byte is split into the ASCII representation of the value. So if the value=0xA3, the Checksum values in the message protocol would be 0x41 and 0x33. Below is the C code which does the Xsum calculation on the message and the method which converts it to binary.
The washlights have no direct decompression signal message. If the ACP receives a decompression signal then the ACP should simply send a 100% white intensity command to all lighting units.
If an LRU loses communications with the ACP, it may remain in the last state which it was commanded, or it can be configured to go to some predefined default state.
Corrective algorithms and look-up tables may be utilized to calibrate lighting devices for color matching, white color temperature matching, matching over various intensities, aging, thermal compensation, wavelength shift, and use of various LED manufacturers. This may be done at the individual device, LRU, subassembly and complete application level. Corrections may be performed and stored in the lighting devices, LRUs and/or other remote devices including master controllers, etc.
Corrective algorithms and look-up tables may be utilized to calibrate lighting devices for color matching, white color temperature matching, matching over various intensities and use of various LED manufacturers (to accommodate variations between manufacturers). This can be done at the individual device (LED 130, LED groups 120), LRU (module 110, module groups 60), subassembly (module groups 60, regional lighting groups 20) and complete application (system 10) level. Corrections may be performed and stored in the lighting devices, LRUs 60, 110 and/or other remote devices including master controllers 30, etc.
It has been recognized that lighting devices 130 can change over time and can change based on usage (power) and environmental conditions. For example, where a change over the lifetime of an LED is known, the operation time of a module 110 can be tracked, and look-up tables can be provided to compensate and adjust for the change over time. Thus, if an LED was known to fall off to 98% brightness after 200 hrs. use, the time for the module could be tracked and at 200 hrs., a new adjustment value could be applied for that module, or, since it is possible to address LED groups and even single LEDs, it could be possible to resolve the new adjustment values down to the single LED level, if desired. By using look-up tables (LUTs), known variance characteristics of LEDs over time can be compensated for. As noted previously, these tables can reside at the system level on the system controller 30, at the module group/module level on the group controller 90, or could be shared between the two.
Similarly, characteristics that vary over temperature could be similarly provided in LUTs or some other form of database. Thus, when the modules 110 are ready to ship from the manufacturer, an initial calibration procedure may be performed to determine the exact color wavelength or x, y coordinates on a color chromaticity diagram, and predetermined tables capable of correcting the LEDs as they age or as they are operated at different temperatures can be provided prior to shipment of the manufactured device.
Furthermore, the LUTs or other database parameters could be fixed, or, preferably, could be updatable so that as new characteristics of the LEDs are learned—including LED bin boundary conditions and parameters including color coordinates, flux and intensity ratings, and manufacturer's component testing tolerance—the tables can be adjusted accordingly. In this way, corrective adjustments based on LED bin characteristics, temperature, and lifetime use of the modules can be provided.
In one embodiment, calibration can be done via an internal and/or external optical sensor that accurately reads the color and intensity information produced by a module 110 or module group 60, and adjustment information can be determined based on this feedback. Updated adjustment information can then be provided directly or indirectly into the lighting device, LRU 60, 110, master controller 30, etc.
The following describes an additional exemplary embodiment and communications for an implementation of the system. The ACP is the main interface point for cabin attendants and maintenance personnel, and it allows input from users to execute the various cabin lighting scenarios inside the aircraft cabin as well as configure address and view BIT information from its LCD touch screen interface.
In this embodiment, all lighting LRUs maintain their scene information locally in the LRU. The ACP is responsible for commanding the lighting system to the specific scene that has been selected by the cabin crew. Lighting assemblies have the capability to receive messages from the ACP via RS485. The lighting assemblies are individually addressable enabling the ACP to individually communicate with each lighting assembly, or to communicate with a group of lighting assemblies. Lighting assemblies also have the capability of being BIT tested to detect if the assembly is still communicating with the system. BIT information from the lighting system can then be viewed on the ACP.
In this embodiment, the lighting LRUs have the capability to have sixteen pre-programmed scenes and sixteen re-programmable scenes. The pre-programmed scenes do not have the ability to be altered. The reprogrammable scenes can be altered onboard the aircraft by the ACP without the need to re-work the devices on a bench. The lighting scenarios are static, and transition at a variable rate do not to exceed 5 minutes from one scene to another. In this embodiment, the physical layer requirements are as follows:
The ACP is the controlling focus of the lighting system. The protocol requirements are the timing and transmission guidelines the ACP in an embodiment of the invention follow for the lighting system to operate correctly.
Each lighting LRU in this embodiment incorporates an individual and unique address. This address helps to identify the location of the lighting LRU in the aircraft. Using a lighting LOPA, an individual could determine the exact position of the light in the aircraft. The SCENE SELECTION message allows the ACP to select a lighting scene for a specific LRU, a Zone of Lights or the entire aircraft. The scene selection message allows the ACP to select either preloaded aircraft lighting scenes or customer specific lighting scenes.
Source Device: ACP—Destination Device: Lighting LRUs
Standard Scenes: 0x30 offset+4 bit scene number. 16 scenes max
Customer Specific Scenes: 0xC0 offset+4 bit scene number. 16 scenes max.
<INTENSITY> [0x31-0x34]—Denotes the relative intensity setting for the scene selected.
0x31=HIGH
0x32=MED
0x33=LOW
0x34=NIGHT
Generally, the ACP controls addressing of the washlights, however, if the ACP has specific ports dedicated to individual or groups of LRU's, addressing the lights may not be required since they all would be “home run” to dedicated ports on the ACP. When addressing is required, the ACP can use the Token Line in addition to the RS485 line to help address the washlights. In this embodiment, each washlight LRU has an RS485 transceiver, Token-In and Token-Out Lines.
The token lines are used to identify, which washlight is currently being addressed. If a washlight's Token-In line is active, then the washlight is currently being addressed and any Address Assignment Messages are intended solely for that LRU. If the washlight receives the address input message it will acknowledge the receipt of an address with an Address Response Message. This signifies that addressing is complete for the LRU and it is time to move on to the next LRU.
Next, the ACP can pass the token by sending a Pass Token Command which will allow the next washlight in the column to be addressed. Once this is received, the currently addressed washlight will set its Token-Out line active so that the next sequential washlight can be addressed. In conjunction, the previous addressed LRU should set its Token-Out line inactive to complete addressing operations for the currently addressed LRU.
Source Device: ACP—Destination Device: Lighting LRUs
<DEST MODE>=[0x30]—The destination mode selection byte
0x30=Broadcast Message
<DEST>=[0x30]—The Destination Address.
<DEST MODE>=0x30:
<DEST>=[0x30]—Don't Care
<CMD>=[0x10]—This command sets the washlights address.
<DATA>=<Address><Group/Zone>
<Address>=[0x21-0xFF] 0x20 offset+address, MAX possible LRUs=222
<Group/Zone>=[0x30-0xFF]—Group/Zone Assignment
Protocol—Address Response Message
Source Device: Addressed Lighting LRU—Destination Device: ACP
<CMD>=[0x1F]—This command is the acknowledgement message from the washlight.
<DATA>=<Address><Device ID><Serial #><Hardware Rev><Firmware Rev>
<Address>=[0x21-0xFF]—The newly assigned address of the LRU 0x20 offset+address value, MAX possible LRUs=222
<Device ID>=[0x41-0x43]—The LRU type.
[0x41]=9100 Direct Lights (W+A)
[0x42]=9150 Bin Wash Lights (W+A)
[0x42]=9150 COS Wash Light (W+A)
[0x43]=9200 Ceiling Wash Lights (RGB+W)
[0x43]=9200 Sidewall Wash Lights (RGB+W)
[0x43]=9200 Cove Wash Light (RGB+W)
[0x43]=9250 Over-Wing Exit Wash Lights (RGB+WW)
<Serial #>=20 ASCII bytes denoting LRU Serial Number (Stored in LRU non-volatile memory)
<Hardware Rev>=20 ASCII bytes denoting LRU Hardware Rev (Stored in LRU non-volatile memory)
<Firmware Rev>=20 ASCII bytes denoting LRU Firmware Rev Number (Stored in LRU non-volatile memory)
Source Device: ACP—Destination Device: Lighting LRUs
<Addressing Complete>=0x31 when the last washlight is being addressed.
<DEST MODE>=[0x32]—The destination mode selection byte
0x32=Address Message
<DEST>=[0x20-0xFF]—The Destination Address.
<DEST MODE>=0x32:
<DEST>=[0x21-0xFF] 0x20 offset+address, MAX possible LRUs=222
<CMD>=[0x11]—This command tells the washlights to pass the token
<DATA>=<Addressing Complete>
<Addressing Complete>=1 byte indicating that addressing is complete
[0x30]=Addressing is not complete
[0x31]=Addressing is complete.
The ACP can control when BIT/BITE is initiated. The ACP can use, e.g., the RS485 line to poll each washlight in the system to determine if the washlight is still active. In addition to polling each LRU, when a washlight receives a BIT request, this sets the light intensity and colors to a specific level which provide visual lamp test functionality. All BIT/BITE requests should be processed and acknowledged from the lighting LRUs within 50 ms.
Source Device: ACP—Destination Device: Lighting LRUs
Source Device: Addressed Lighting LRU—Destination Device: ACP
<CMD>=[0x3F]—This command is the acknowledgement message from the washlight.
<DATA>=<Address><Device ID><Serial #><Hardware Rev><Firmware Rev>
<B Scene Rev><User Scene Rev><Cal Flag>
<Address>=[0x21-0xFF]—The newly assigned address of the LRU
0x20 offset+address value, MAX possible LRUs=222
<Device ID>=[0x41-0x43]—The LRU type.
[0x41]=9100 Direct Lights (W+A)
[0x42]=9150 Bin Wash Lights (W+A)
[0x42]=9150 COS Wash Light (W+A)
[0x43]=9200 Ceiling Wash Lights (RGB+W)
[0x43]=9200 Sidewall Wash Lights (RGB+W)
[0x43]=9200 Cove Wash Light (RGB+W)
[0x43]=9250 Over-Wing Exit Wash Lights (RGB+WW)
<Serial #>=20 ASCII bytes denoting LRU Serial Number (Stored in LRU non-volatile memory)
<Hardware Rev>=20 ASCII bytes denoting LRU Hardware Rev (Stored in LRU non-volatile memory)
<Firmware Rev>=20 ASCII bytes denoting LRU Firmware Rev Number (Stored in LRU non-volatile memory)
<B Scene Rev>=20 ASCII bytes denoting LRU aircraft Scenes P/N and Rev Number (Stored in LRU non-volatile memory)
<User Scene Rev>=20 ASCII bytes denoting LRU User Scenes P/N and Rev Number (Stored in LRU non-volatile memory)
<Cal Flag>=1 byte indicating that the washlight is calibrated
0x30=Washlight is not calibrated
0x31=Washlight is calibrated
The Scene Download operation is used to update the locally stored scenes on the lighting LRUs. The ACP controls when the Scene Download Operation is initiated. The ACP can use the RS485 line to help store the scene information into each washlight in the system. The ACP first sends a SCENE DOWNLOAD REQUEST message to all washlights in the system. This instructs the washlights to allow protected EEPROM space to be altered. The ACP can then transmit the SCENE CONTENT message for each scene. The scene content message contains the scenes information one scene at a time.
Once all the new scenes have been transmitted, the ACP can poll each washlight with a SCENE QUERY REQUEST message. The Scene query message can ask the washlight if it has received all the scenes. The washlight replies with a SCENE QUERY REPLY message notifying the ACP it has received/not received all the information. If the washlight has received the information, it should commit all the scene information to non-volatile EEPROM. If the washlight responds that it has not received all the information, the ACP should retransmit the SCENE CONTENT message again to all the washlights and resume re-querying the washlights.
All SCENE QUERY REQUEST messages should be processed and acknowledged by the Lighting LRUs within 50 ms.
Source Device: ACP—Destination Device: Lighting LRUs
Source Device: ACP—Destination Device: Lighting LRUs
The scene content message may be a broadcast message. Every lighting LRU should receive this message.
Source Device: ACP—Destination Device: Lighting LRUs
Source Device: Addressed Lighting LRU—Destination Device: ACP
Message to its internal database, in order to ascertain that the correct information is stored in the lighting assembly. Any discrepancy in returned information should alert the operator to the problem.
<CMD>=[0x5F]—This command is the acknowledgement message from the washlight.
<DATA>=<Address><B Scene Rev><User Scene Rev>
<Address>=[0x21-0xFF]—The address of the queried washlight 0x20 offset+address value, MAX possible LRUs=222
<B Scene Rev>=20 ASCII bytes denoting LRU aircraft Scenes P/N and Rev Number (Stored in LRU non-volatile memory)
<User Scene Rev>=20 ASCII bytes denoting LRU User Scenes P/N and Rev Number (Stored in LRU non-volatile memory)
The Scene configuration database is the file which stores the information on custom lighting scenes. This database may be generated externally using a Cabin Lighting Designer program. The database comprises, e.g., the 16 scene content messages separated by ASCII carriage return line feeds.
The lighting LOPA configuration database helps to configure the exact light layout on the aircraft. It can contain the descriptions for each lighting LRU, station location as well as firmware/hardware and database revision information. The database file format may comprise multiple device types ( ) separated by an ASCII carriage return and line feed. The ACP can check the validity of the database with the XSUM calculation at the end of the file.
Although the above has been described for use as lighting within an aircraft the invention is not limited and can apply to other applications as well. The term “aircraft” as used herein is to be understood as a proxy for any passenger vehicle or any illuminated area. Similarly, the term LED or light-emitting diode is to be understood as a proxy for any illumination source that can be controllable in a manner similar to that described herein.
The system or systems may be implemented on any general purpose computer or computers and the components may be implemented as dedicated applications or in client-server architectures, including a web-based architecture. Any of the computers may comprise a processor, a memory for storing program data and executing it, a permanent storage such as a disk drive, a communications port for handling communications with external devices, and user interface devices, including a display, keyboard, mouse, etc. When software modules are involved, these software modules may be stored as program instructions executable on the processor on media such as tape, CD-ROM, etc., where this media can be read by the computer, stored in the memory, and executed by the processor.
For the purposes of promoting an understanding of the principles of the invention, reference has been made to the preferred embodiments illustrated in the drawings, and specific language has been used to describe these embodiments. However, no limitation of the scope of the invention is intended by this specific language, and the invention should be construed to encompass all embodiments that would normally occur to one of ordinary skill in the art.
The present invention may be described in terms of functional block components and various processing steps. Such functional blocks may be realized by any number of hardware and/or software components configured to perform the specified functions. For example, the present invention may employ various integrated circuit components, e.g., memory elements, processing elements, logic elements, look-up tables, and the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. Similarly, where the elements of the present invention are implemented using software programming or software elements the invention may be implemented with any programming or scripting language such as C, C++, Java, assembler, or the like, with the various algorithms being implemented with any combination of data structures, objects, processes, routines or other programming elements. Furthermore, the present invention could employ any number of conventional techniques for electronics configuration, signal processing and/or control, data processing and the like. The word mechanism is used broadly and is not limited to mechanical or physical embodiments, but can include software routines in conjunction with processors, etc.
The particular implementations shown and described herein are illustrative examples of the invention and are not intended to otherwise limit the scope of the invention in any way. For the sake of brevity, conventional electronics, control systems, software development and other functional aspects of the systems (and components of the individual operating components of the systems) may not be described in detail. Furthermore, the connecting lines, or connectors shown in the various figures presented are intended to represent exemplary functional relationships and/or physical or logical couplings between the various elements. It should be noted that many alternative or additional functional relationships, physical connections or logical connections may be present in a practical device. Moreover, no item or component is essential to the practice of the invention unless the element is specifically described as “essential” or “critical”.
The use of the terms “a” and “an” and “the” and similar referents in the context of describing the invention (especially in the context of the following claims) are to be construed to cover both the singular and the plural. Furthermore, recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Finally, the steps of all methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context.
Numerous modifications and adaptations will be readily apparent to those skilled in this art without departing from the spirit and scope of the present invention.
The present application is a continuation-in-part of U.S. patent application Ser. No. 12/566,146, filed on Sep. 24, 2009, which claims the priority benefit of U.S. Provisional Application No. 61/099,713, filed Sep. 24, 2008, entitled, “An Aircraft LED Washlight System and Method for Controlling Same” and U.S. Provisional Application No. 61/105,506, filed Oct. 15, 2008, entitled, “An Aircraft LED Washlight System and Method for Controlling Same.” The present application claims the priority benefit of the above-referenced applications, and also claims the priority benefit of U.S. Provisional Application No. 61/308,171, filed Feb. 25, 2010, entitled “Lighting System for Vehicle Cabin,” U.S. Provisional Application No. 61/320,545, filed Apr. 2, 2010, entitled “Lighting System for Vehicle Cabin,” and U.S. Provisional Application No. 61/345,378, filed May 17, 2010, entitled “Lighting System for Vehicle Cabin.” All of the above-referenced applications are herein incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61099713 | Sep 2008 | US | |
| 61105506 | Oct 2008 | US | |
| 61308171 | Feb 2010 | US | |
| 61345378 | May 2010 | US | |
| 61320545 | Apr 2010 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12566146 | Sep 2009 | US |
| Child | 13034983 | US |
