US20130062966A1

US20130062966A1 - Reconfigurable control architectures and algorithms for electric vehicle wireless energy transfer systems

Info

Publication number: US20130062966A1
Application number: US13/612,494
Authority: US
Inventors: Simon Verghese; Morris P. Kesler; Katherine L. Hall; Herbert Toby Lou; Ron Fiorello
Original assignee: WiTricity Corp
Current assignee: WiTricity Corp
Priority date: 2011-09-12
Filing date: 2012-09-12
Publication date: 2013-03-14
Also published as: US20170066335A1; US20220144092A1; US10424976B2; US11097618B2; US20200014254A1

Abstract

A control architecture for electric vehicle wireless power transmission systems that may be segmented so that certain essential and/or standardized control circuits, programs, algorithms, and the like, are permanent to the system and so that other non-essential and/or augmentable control circuits, programs, algorithms, and the like, may be reconfigurable and/or customizable by a user of the system. The control architecture may be distributed to various components of the wireless power system so that a combination of local or low-level controls operating at relatively high-speed can protect critical functionality of the system while higher-level and relatively lower speed control loops can be used to control other local and system-wide functionality.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional patent application 61/533,281 filed Sep. 12, 2011 and U.S. provisional patent application 61/566,450 filed Dec. 2, 2011.

BACKGROUND

1. Field
This disclosure relates to wireless energy transfer and methods for controlling the operation and performance of electric vehicle wireless power transmission systems.
2. Description of the Related Art
Energy or power may be transferred wirelessly using a variety of known radiative, or far-field, and non-radiative, or near-field, techniques as detailed, for example, in commonly owned U.S. patent application Ser. No. 12/613,686 published on May 6, 2010 as US 2010/010909445 and entitled “Wireless Energy Transfer Systems,” U.S. patent application Ser. No. 12/860,375 published on Dec. 9, 2010 as 2010/0308939 and entitled “Integrated Resonator-Shield Structures,” U.S. patent application Ser. No. 13/222,915 published on Mar. 15, 2012 as 2012/0062345 and entitled “Low Resistance Electrical Conductor,” U.S. patent application Ser. No. 13/283,811 published on ______ as U.S. Pat. No. ______ and entitled “Multi-Resonator Wireless Energy Transfer for Lighting,” the contents of which are incorporated by reference.
Recharging the batteries in full electric vehicles currently requires a user to plug a charging cord into the vehicle. The many disadvantages of using a charging cord, including the inconvenience, weight, and awkwardness of the cord, the necessity of remembering to plug-in and un-plug the vehicle, and the potential for cords to be stolen, disconnected, damaged, etc., have motivated makers of electric vehicles to consider wireless recharging scenarios. Using a wireless power transmission system to recharge an electric vehicle has the advantage that no user intervention may be required to recharge the vehicle's batteries. Rather, a user may be able to position a vehicle near a source of wireless electricity and then an automatic control system may recognize that a vehicle in need of charge is present and may initiate, sustain, and control the delivery of wireless power as needed.
One of the advantages of wireless recharging of electric vehicles is that the vehicles may be recharged using a variety of wireless power techniques while conforming to a variety of performance criteria. The variety of available wireless power techniques and acceptable performance criteria may present challenges to system designers who may like to provide for interoperability between different wireless sources and wireless devices (usually integrated in the vehicles) and at the same time differentiate their products by offering certain enhanced features. Therefore there is a need for an electric vehicle wireless power system control architecture that may ensure safe, efficient and reliable performance that meets certain industry performance standards and that offers designers and users of the end-system the opportunity to customize their systems to offer differentiated and enhanced features to the drivers of their vehicles.

SUMMARY

This invention relates to a control architecture for electric vehicle (EV) wireless power transmission systems that may be segmented so that certain essential and/or standardized control circuits, programs, algorithms, and the like, are permanent to the system and so that other non-essential and/or augmentable control circuits, programs, algorithms, and the like, may be reconfigurable and/or customizable by a user of the system. In addition, the control architecture may be distributed to various components of the wireless power system so that a combination of local or low-level controls operating at relatively high-speed can protect critical functionality of the system while higher-level and relatively lower speed control loops can be used to control other local and system-wide functionality. This combination of distributed and segmented control may offer flexibility in the design and implementation of higher level functions for end-use applications without the risk of disrupting lower level power electronics control functions.
The inventors envision that the control architecture may comprise both essential and non-essential control functions and may be distributed across at least one wireless source and at least one wireless device. Non-essential control functions may be arranged in a hierarchy so that, for example, more sophisticated users may have access to more, or different reconfigurable control functions than less sophisticated users. In addition, the control architecture may be scalable so that single sources can interoperate with multiple devices, single devices can interoperate with multiple sources, and so that both sources and devices may communicate with additional processors that may or may not be directly integrated into the wireless power charging system, and so on. The control architecture may enable the wireless power systems to interact with larger networks such as the internet, the power grid, and a variety of other wireless and wired power systems.
An example that illustrates some of the advantages of the distributed and segmented architecture we propose is as follows. Imagine that an original equipment manufacturer (OEM) of an EV wireless power transmission system may need to provide a system with certain guaranteed and/or standardized performance such as certain end-to-end transmission efficiency, certain tolerance to system variations, certain guarantees for reliability and safety and the like. An integrator who integrates the wireless power transmission system into an electric vehicle may wish to distinguish their vehicle by guaranteeing higher efficiency and/or more robust safety features. If the control architecture is structured in such a way that the integrator can set certain thresholds in the control loops to ensure higher efficiency and/or may add additional hardware (peripherals) to the system to augment the existing safety features, then the integrator may be able to offer significant product differentiation while also guaranteeing that basic system requirements and/or standards are met. However, if the control architecture is not segmented to offer some reconfigurable functions while protecting the critical functions of the wireless power system, changing certain control loops and/or adding additional hardware may disrupt the required low-level power delivery, reliability, and safety performance of the system.
Note that the inventive control architecture described in this disclosure may be applied to wirelessly rechargeable electric vehicles using traditional inductive and magnetic resonance techniques. Because the performance of traditional inductive wireless power transmission systems is limited compared to the performance of magnetic resonance power transmission systems, the exemplary and non-limiting embodiments described in this disclosure will be for magnetic resonance systems. However, it should be understood that where reference is made to source and device resonators of magnetic resonance systems, those components may be replaced by primary coils and secondary coils in traditional inductive systems. It should also be understood that where an exemplary embodiment may refer to components such as amplifiers, rectifiers, power factor correctors and the like, it is to be understood that those are broad descriptions and that amplifiers may comprise additional circuitry for performing operations other than amplification. By way of example but not limitation, an amplifier may comprise current and/or voltage and/or impedance sensing circuits, pulse-width modulation circuits, tuning circuits, impedance matching circuits, temperature sensing circuits, input power and output power control circuits and the like.
In one aspect of the invention a wireless energy transfer system may include a segmented control architecture. The wireless system may include a primary controller and a user configurable secondary controller that is in communication with the primary controller. The primary controller may be configured to perform the essential control functions for the wireless system. The essential control functions of the primary controller may include maintaining the wireless energy transfer operating safety limits. The primary controller may monitor and control the voltage and currents on the components of the wireless energy transfer system. The user configurable secondary controller may be configured to allow adjustment of non-safety critical parameters of the system such as adjusting the maximum power output, scheduling of on and off times, adjusting the frequency of energy transfer, and the like. In accordance with exemplary and non-limiting embodiments the primary and secondary controllers may be implemented on separate hardware or processors. In other exemplary embodiments the primary and secondary controllers may be virtual controllers and implemented on the same hardware.

BRIEF DESCRIPTION OF FIGURES

FIG. 1 shows exemplary components in an electric vehicle wireless power transfer system.

FIG. 2 shows an exemplary charging system control diagram for an electric vehicle wireless power transfer system. This exemplary embodiment shows that system performance may be monitored with a laptop through the wireless and/or wired “Debug” and “Status” ports.

FIG. 3A shows a notional state diagram of the system charging cycle. Activation states are denoted by the rectangles. Conditional statements that enable transitions between states are enclosed in square brackets. Fault detection on either side results in both sides entering the Anomaly state.

FIG. 4 shows an exemplary charging cycle use-case.

FIG. 5 shows a Sequence Diagram for interaction between a source and an electric vehicle during an exemplary charging engagement.

FIG. 6 shows an exemplary embodiment of power factor corrector control loops.

FIG. 7 shows an exemplary embodiment of source amplifier control loops.

FIG. 8 shows an exemplary embodiment of device rectifier control loops.

FIG. 9 shows exemplary interfaces to and from an application source processor.

FIG. 10 shows exemplary interfaces to and from an application device processor.

FIG. 11 shows exemplary interfaces to and from an amplifier controller.

FIG. 12 shows exemplary interfaces to and from a recitfier controller.

FIG. 13 shows exemplary ASP control parameters.

FIG. 14 shows exemplary ADP control parameters.

FIG. 15 shows exemplary amplifier control parameters.

FIG. 16 shows exemplary rectifier control parameters.

DETAILED DESCRIPTION

This disclosure describes exemplary reconfigurable system control concepts for electric vehicle wireless power transmission systems. In general, an electric vehicle (EV) may be any type of vehicle such as a car, a boat, a plane, a bus, a scooter, a bike, a cart, a moving platform, and the like that comprises a rechargeable battery. The wireless power transmission system may provide power to the battery charging circuit of the electric vehicle and/or it may power the vehicle directly. Wireless power may be provided to the vehicle while it is stationary or while it is moving. The power provided wirelessly to recharge the vehicle battery may be more than 10 Watts (W), more than 100 W, more than a kilowatt (kW), more than 10 kW, and/or more than 100 kW, depending on the storage capacity and power requirements of the vehicle. In some exemplary low power embodiments, fewer control loops and/or less distributed and/or less segmented control architectures may be sufficient to ensure safe, reliable and efficient operation of the wireless power transmission system. In some exemplary high power embodiments, redundant control loops and/or multi-level control architectures may be required to realize safe, reliable and efficient operation of the wireless power transfer system.
This disclosure describes certain control tasks that may be necessary for enabling an electric vehicle charging engagement using a wireless energy transfer system as well as potential control loops, states, and sequences of interactions that may govern the performance of the system. The proposed control architectures and tasks may enable transaction management (e.g. billing, power origination identification, direction of power flow), integration with vehicle electronics, and higher level control tasks for system operation, communications, and anomaly resolution. Throughout this disclosure we may refer to certain parameters, signals, and elements as being variable, tunable, controllable, and the like, and we may refer to said parameters, signals and elements as being controlled. It should be understood that system parameters, signals and elements may be controlled using hardware control techniques, software control techniques, and/or a combinations of hardware and software control techniques, and that these techniques and the circuits and circuit elements used to implement them may be referred to as controllers and/or system controllers.
A block diagram of an exemplary wireless electric vehicle (EV) battery charging system is shown in FIG. 1. In this exemplary embodiment the system is partitioned into a source module and a device module, with each module consisting of a resonator and module control electronics. The source module may be part of a charging station and the device module may be mounted onto a vehicle. Power may be wirelessly transferred from the source to the device via the resonators. Closed loop control of the transmitted power may be performed through an out-of-band communications link between the source and the device, an in-band communications link between the source and the device, or a combination of in-band and out-of-band signaling protocols between the source and device. In some exemplary and non-limiting embodiments, some or all of the system control functions may be realized in a computer, processor, server, network node and the like, separated from the source and device modules. In some exemplary embodiments, the system controller may control more than one source, more than one device and/or more than one system.
A wireless power transmission system for electric vehicle charging can be designed so that it may support customization and modifications of the control architecture. Such customizations and modifications may be referred to as reconfigurations, and an architecture designed to support such reconfigurations may be referred to as reconfigurable. In some exemplary and non-limiting embodiments, the control architecture may be realized in physically separate components, such as multiple microprocessors and some functions, processes, controls, and the like may be reconfigurable by a user of the system, and some may not. In some exemplary and non-limiting embodiments, the reconfigurable portions of the control architecture may be implemented in certain chips, micro-processors, field programmable gate arrays (FPGAs), Peripheral Interface Controllers (PICs), Digital Signal Processors (DSPs), Application Specific Processors (ASPs), and the like. In an exemplary embodiment, some reconfigurable portions of the control architecture may reside in ASPs which may be 32-bit microcontrollers with C-language source code. In some exemplary and non-limiting embodiments, the control code may reside on a single processor and a user may have permission to access certain portions of the code. In exemplary and non-limiting embodiments, both hardware and software segmentation of the control functions of an EV wireless power transmission system are contemplated in this disclosure.
In an exemplary embodiment, the system architecture may support ASPs in the source and device modules and these processors may be referred to as Application Source Processors (ASP) and the Application Device Processors (ADP). This control architecture may enable different users and/or manufacturers of different vehicles and vehicle systems to be able to add to the source code or customize it for integration with their vehicles and/or in their intended applications. Throughout this disclosure we may use the terms processor, microprocessor, controller, and the like to refer to the ASPs described above and any suitable type of microprocessor, field programmable gate array (FPGA), Peripheral Interface Controller (PIC), Digital Signal Processor (DSP), and the like, that is known to one of skill in the art. In exemplary and non-limiting embodiments, the ASP and ADP may be used to present certain system parameters and control points to wireless power system designers and/or vehicle integrators and to restrict access to certain other system parameters and control points. For example, certain control features may be essential to ensure proper and/or safe operation of a wireless power transmission system, and such control features may be implemented in hardware only loops and/or in physically separated microcontrollers and/or in restricted portions of the ASPs so that they may not be customized and/or modified by certain users of the systems.
In exemplary and non-limiting embodiments, one, some or all of the control functions of the wireless power system may be based on hardware implementations and/or may be hard-coded into the system and/or may be soft-coded into the system but with restricted access so that only select and verified users may make changes to the various codes, programs, algorithms and the like, that control the system operation.
Note that whether or not the functionality associated with the ASPs in this exemplary embodiment are realized in physically separate hardware components or in isolated sections of code, the concept of partitioning the control plane into at least source-side and device-side functions and into at least high-level and low-level functions is what enables the reconfigurability of system operation while guaranteeing certain safety, reliability and efficiency targets are met. The distribution and segmentation of the control plane allows flexibility in the adaptation of the higher level functions for vehicle designer and/or end user applications without the risk of disrupting the operation of the low level power electronics control functions. In addition, the partitioning of the control plane allows for variable control loop speeds; fast and medium speeds for the low level critical hardware control functions of the power electronics as well as slower control loop speeds for the high level designer and/or end user control loops.
As time goes on, this partitioned control plan architecture may scale to adjust to and support more functionality and applications, at the same time it may be adapted to changing hardware requirements and standardized requirements for the safe and efficient delivery of power. For example, the fast and medium speed control loops may be adapted to support wireless power transmission at a range of operating frequencies and over a range of coupling coefficients, both of which may eventually be set by regulatory agencies. Also, users may access and customize the higher level control functions to implement functionality that may include, but may not be limited to:

- Programming an EV wireless source to connect through a wired internet connection in the source, or through Wi-Fi or the cellular network to display certain source attributes such as what type of resonator it comprises, how much energy it can supply, what the price is for the energy it supplies (this price may change during the day, being less expensive at night when the peak demand for electricity is lower, or it may change seasonally, costing more when the temperature is hot and air conditioning requirements are stressing the electrical suppl), where the energy it supplies originates from (renewables, coal plant, etc.), does this source require a reservation, if it requires a reservation, when are the free times that can be reserved, what type of FOD detectors does it deploy, what is the status of the source (has FOD been detected and needs to be cleaned off before charging can be initiated, or has FOD been detected and so the source can only supply a limited amount of power).
- Programming an EV wireless power transfer system so that it may connect to a communication network and may contact the vehicle user to report the status of the charge cycle and to report when charging is complete or when charging has been interrupted or that the source and/or device are in an anomaly state.
- Programming an EV wireless power transfer system so that power is transmitted from the device back to the grid and managing the transaction so that the vehicle user is paid for supplying that energy.
- Programming a user interface in the vehicle so that information regarding the position of the vehicle resonator relative to the source resonator can be relayed to the driver of the vehicle. The relative position information may be used to give the vehicle driver an estimate of the wireless transfer efficiency with the vehicle in its current location and may offer the driver a chance to change the parking position to improve the wireless system performance. The user interface may include visible, audible, vibrational and the like feedback to help the driver reposition the vehicle.
- Programming an EV wireless power transfer system so that it communicates with an automatic vehicle parking capability resident on the vehicle and parks the vehicle in a position that is optimized for wireless power transfer efficiency. Other commands that may be communicated from the EV wireless power transmission system to the vehicle may include commands to control the active suspension of the vehicle to raise or lower the vehicle relative to the source to optimize wireless power transfer.

FIG. 2 shows an exemplary charging system control diagram for an electric vehicle wireless power transfer system. In this block diagram, the source components of the system are shown on the left side of the diagram and the device (or vehicle) components of the system are shown on the right.
In exemplary and non-limiting embodiments, AC line power may flow into a power factor corrector (PFC) and provide a DC voltage to a switching amplifier. In exemplary and non-limiting embodiments, the DC voltage provided to the switching amplifier may be variable and may be controlled. In exemplary and non-limiting embodiments, a DC voltage may be provided to the amplifier from a DC source of power (not shown) such as a solar cell, a battery, a fuel cell, a power supply, a super capacitor, a fly wheel, and the like. In exemplary and non-limiting embodiments, the DC voltage from a DC power source may be variable and may be controlled.
The switching amplifier in the source of an electric vehicle wireless power transmission system may be any class of switching amplifier including, but not limited to, a class D amplifier, a class E amplifier and a class D/E amplifier. The switching frequency of the amplifier may be any frequency and may preferably be a frequency previously identified as suitable for driving inductor coils and/or magnetic resonators. In exemplary and non-limiting embodiments, the switching frequency may be between 10 kHz and 50 MHz. In exemplary and non-limiting embodiments, the frequency may be approximately 20 kHz, or approximately 44 kHz, or approximately 85 kHz, or approximately 145 kHz, or approximately 250 kHz. In exemplary and non-limiting embodiments, the switching frequency may be between 400 and 600 kHz, between 1 and 3 MHz, between 6 and 7 MHz, and/or between 13 and 14 MHz. In exemplary and non-limiting embodiments, the frequency of the switching amplifier may be tunable and may be controlled.
In exemplary and non-limiting embodiments, an amplifier controller may manage the electronic components in the amplifier and/or in the PFC and/or in the DC power supply (not shown). The amplifier controller may monitor and control so-called local control loops and local interlocks for conditions such as over voltage/current in the source electronics, ground-fault circuit interrupt in the source electronics, and out-of-specification AC impedance changes at the source coil. In exemplary and non-limiting embodiments, the amplifier controller may react quickly to shut the system down safely in response to a variety of set point violations. The amplifier controller may expose registers for set-points and control to the ASP through an inter-integrated circuit (I²C) interface, referred to in the figure as the “User Interface”. The amplifier controller may also have a watchdog timer (or heartbeat input) to detect if communication with the Application Source Processor (ASP) or with the vehicle has been lost.
In an exemplary embodiment, the ASP may provide high-level control of the source electronics and the overall system charging cycle. For example, the ASP may interface with a foreign-object-debris (FOD) detector that monitors the source module for the presence of FOD and/or excessive temperature. The ASP may be connected to an in-band and/or out-of-band communications link that may communicate with the vehicle-side application device processor (ADP) to provide closed loop control of the charging cycle.
In an exemplary embodiment on the vehicle side (also called the device side), a rectifier controller may perform low-level and local functions for the device side that are analogous to those described for the source side. Again, an I²C interface may be provided for interfacing with a higher-level ADP. The ADP could be configured to connect via a CAN-bus or equivalent to a battery manager that may control the power delivered from the rectifier to the battery, vehicle engine or any time of power storage or management system on the vehicle. The ADP could communicate that information to the source-side ASP which, in turn, could adjust the power settings on the amplifier controller.
In an exemplary embodiment, the control architecture may be partitioned into three types of control loops: fast, medium and slow. The fast control loops may be for time critical functions (less than 1-ms latency) and may be either hardware control loops or interrupt-driven low-level software modules. Medium-speed control loops may be for functions that operate under real-time software control (<500-ms latency). Slow control loops (>500 ms latency) may be for functions with low bandwidth requirements or functions with unpredictable latency, for example, a 802.11-family wireless communication link.
FIG. 2 shows the three types of control loops as they may be applied to an exemplary electric vehicle wireless power transmission system. In exemplary and non-limiting embodiments, embedded software portions of the control loops may be partitioned between the amplifier and rectifier controllers and the processors (ASP and ADP). The amplifier and rectifier controllers may handle the hardware control and the operation of high-power and/or sensitive electronics components. The ASPs may handle the system control loop and may provide interfaces to external peripherals, such as FOD detectors, communication links, monitoring equipment, and other vehicle and source electronics.
In exemplary and non-limiting embodiments, some of the functions that may operate under fast feedback-loop control may be based on hardware set-points and/or on software (programmable) set-points which may include but may not be limited to over-current protection, over-voltage protection, over-temperature protection, voltage and current regulation, transistor shoot-through current in the switching amplifier, GFCI (ground fault circuit interrupt) and critical system interlocks. In exemplary and non-limiting embodiments, system events that may cause damage to the system itself or to a user of the system in a short period of time may be detected and reacted to using fast feedback-loop control.
In exemplary and non-limiting embodiments, some of the functions that may operate under medium-speed feedback loops may include, but may not be limited to temperature set-point violations, impedance set points to declare an out-of-range condition for the source coil impedance, FOD detection, monitoring for violations of the minimum efficiency set point, local power control in the source-side electronics and processor heartbeat monitoring (i.e. watchdog-timer expiration). In exemplary and non-limiting embodiments, system events that may cause damage to the system itself or to a user of the system in a medium period of time and/or that may cause the system to operate in an undesirable state (e.g. low efficiency) may be detected and reacted to using medium feedback-loop control.
In exemplary and non-limiting embodiments, some of the functions that may operate under relatively slow-speed loop control may include but may not be limited to system power control loop (e.g. for executing a battery-charging profile), charge request/acknowledge messages between vehicle(s) and source(s), system start/stop messages, system level interlocks, RF communications link heartbeat monitoring (i.e. watchdog-timer expiration), status/GUI updates to a diagnostic laptop and messages for source/vehicle transactions, authentication and configuration. In exemplary and non-limiting embodiments, system events that may cause damage to the system itself or to a user of the system in a long period of time and/or that may cause the system to operate in an undesirable state (e.g. low efficiency, insufficient information for closing a transaction) may be detected and reacted to using slow feedback-loop control.
FIG. 3 shows a notional state diagram of the system charging cycle. The diagram shows examples of state machines that may be running on the ASPs in the source side and the vehicle side of the EV wireless power transmission system. Potential activation states are shown within each rectangle and potential conditional statements that must be satisfied to enable transitions between states are enclosed in square brackets. In exemplary and non-limiting embodiments, in-band, out-of-band, and/or a combination of in-band and out-of-band wireless communication links between the source and the vehicle may provide for messaging and synchronization. In exemplary and non-limiting embodiments, the communications required to implement control functions, processes and the like may piggy-back on existing or native communication systems in and around the vehicle. For example, messages may be passed amongst the source(s), the vehicle(s), and any additional networked component(s) using CAN-bus equipment and protocols, Bluetooth equipment and protocols, Zigbee equipment and protocols, 2.4 GHz radio equipment and protocols, 802.11 equipment and protocols, and/or any proprietary signaling scheme equipment and protocols implemented by the user.
For charging electric vehicles that may be described in the standards proposed by the Society of Automotive Engineers (SAE), the charging engagement between the source and vehicle for wireless charging may be similar to that described by SAE J1772 for wired charging, with additional steps added to support wireless charging.
An exemplary use-case for stationary EV charging involving the operation of the control system is shown in the table in FIG. 4. In an exemplary embodiment, a wireless source may be powered and available to supply power to a wireless device and may be referred to as being in the Available state. A wireless source may constantly, periodically, occasionally and/or in response to some trigger, broadcast information regarding any of its availability, position, location, power supply capabilities, power costs, power origination (solar, coal burning plant, renewable, fossil fuel, etc.), resonator type, resonator cross-section (so that a vehicle may calculate and/or look-up an expected coupling coefficient with the source), and the like. A vehicle may be receiving information broadcast by wireless power sources and may search for an available wireless power source, with matching hard-wired and/or use selectable features, over which it may park. The vehicle's communication link may be active so that it is in the Searching state. If vehicle identifies a suitable wireless source, it may approach that source and initiate two way communications with the source so that the source and device side control electronics can exchange configuration information. In an exemplary embodiment, when sufficient information has been exchanged by the source and the device, and when the vehicle resonator has been positioned substantially in the near vicinity of the source resonator, the source and vehicle sides may switch to their Docking states.
In an exemplary Docking state, both source and device may confirm their compatibility and an alignment error signal may be provided to the vehicle driver so that he/she can maneuver the car into proper position. Once in position, the drive train of the vehicle may be disabled and the source and device may enter the Coupled state.
In an exemplary embodiment, a ‘Charge Request’ may be sent from the vehicle—either automatically or driver initiated, and may be received by the source. In the Coupled state, there may be further exchange of configuration information, safety checks, and the like. Once those are passed, both sides may enter the Ready to Charge state.
In an exemplary embodiment, in the Ready to Charge state, the vehicle may issue a ‘Start Charging’ command and both the source and the vehicle may enter the Charging state as the source power ramps up. In the Charging state, both source and vehicle may perform monitoring and logging of data, faults, and other diagnostics. Logging and monitoring may include, but may not be limited to an event loop that looks for hazardous and/or restricted Foreign Object Debris (FOD), overloads, unexpected temperature and/or efficiency excursions, and other asynchronous events.
In exemplary and non-limiting embodiments, hazard and/or restricted object detection that occurs in the source during any of the powered states may cause the source to switch into its Anomaly state. If wireless communication is still working, the vehicle may be notified and may also drop into its Anomaly state. If wireless communication is down, the vehicle may enter its Anomaly state because it didn't ask for the wireless power to be shut down and because the wireless communications watchdog timer expires.
In an exemplary embodiment, where the vehicle has entered the Anomaly state, state, the vehicle may send a message to the source that results in the source entering its Anomaly state.
In an exemplary embodiment, where the source has entered the Anomaly state, the source may send a message to the vehicle that results in the vehicle entering its Anomaly state.
In an exemplary embodiment, the source and/or vehicle may automatically begin a process for handling or disposition of the anomaly. The process may involve the source and vehicle exchanging health and status information to help discover the cause of the anomaly. Once the cause is determined, the source and vehicle may select a pre-planned action that corresponds to the cause. For example, in the event that detection of foreign object debris caused the anomaly, the source may reduce the power transfer level to a safe level where the foreign object debris does not overheat. In another example, in the event that the loss of RF communication was the cause, the source may stop power transfer until RF communication is re-established. In exemplary and non-limiting embodiments, where one or both sides of the system may have entered the anomaly state, the system may automatically communicate to a user that the system is in its Anomaly state. Communication may occur over the internet, over a wireless network, or over another communications link.
In an exemplary embodiment, under normal operating conditions, charging may end when the vehicle sends a stop-charging (DONE) command to the source. The source may immediately de-energize.
In this exemplary embodiment, after de-energizing, the source may return to the coupled state and may notify the vehicle of its state change. The vehicle may switch to the Coupled state and may receive additional information about the charge engagement from the source. At this point, the vehicle may either stay put or it may depart. Once the source senses that a vehicle has departed, it may return to the Available state.
Not explicitly shown the figures are exemplary control loops that may perform system safety and hazard monitoring, as well as localized FOD detection, for example. There a many ways a FOD detector might be used including; prior to a source declaring itself Available, it may run through a series of diagnostic tests including FOD detection, in the Docking and in the Coupled states, the FOD detector could check for potentially hazardous debris falling off of a vehicle and onto a source resonator, and before entering the Ready to Charge state, a FOD detector reading may be part of a final safety check. In exemplary and non-limiting embodiments, monitoring for FOD may occur during the Charging state. In exemplary and non-limiting embodiments, one, some or any anomalies or failed safety checks may turn down or shut down the amplifier and put both sides (source and vehicle) into their Anomaly states, where additional diagnostics can be safely performed.
FIG. 5 shows another representation of some potential steps if a sequence of interactions in an exemplary embodiment of an EV wireless power transfer system. The diagram shows exemplary steps from the charging sequence described above following Unified Modeling Language (UML) conventions:

- Time flows in the downward direction
- The vertical bars under each side represent activation of different states
- Arrows with solid lines indicate requests
- Arrows with dashed lines indicate responses
- Full arrow heads represent synchronous messages
- Half arrow heads represent asynchronous messages
- Arrows entering the diagram from off the page represent user actions
  Note that the diagram is not intended to show every message in the exemplary engagement just some examples helpful to understanding the interaction.

In exemplary embodiments of electric vehicle wireless power systems, a variety of control loops may be implemented to govern the operation of the wireless charging and/or powering of the electric vehicle. Some exemplary control loops for the exemplary system shown in FIG. 2 are described below. The control loops described below may be sufficient for some systems or they may need to be modified or added to ensure proper operation of other systems. The description of control loops should not be interpreted as complete, but rather illustrative, to describe some of the issues considered when deciding whether system control loops might be fast, medium or slow in their response time, and whether or not they should be user reconfigurable.
In an exemplary EV wireless power transfer system, a power factor corrector may convert an AC line voltage to a DC voltage for the source. It may provide active power factor correction to the line side and may provide a fixed or variable DC voltage to the source amplifier. Control of a power factor corrector may be performed through a combination of hardware circuits and firmware in the amplifier controller. For example hardware circuits may be used to control against transient or short-duration anomalies, e.g. exceeding hard set-point limits such as local currents or voltages exceeding safety limits for circuit components, such as power MOSFETs, IGBTs, BJTs, diodes, capacitors, inductors, and resistors, and firmware in the amplifier controller may be used to control against longer duration and slower developing anomalies, e.g. temperature warning limits, loss of synchronization of switching circuitry with the line voltage, and other system parameters that may affect power factor controller operation.
In this exemplary embodiment, an amplifier may provide the oscillating electrical drive to the wireless power system source resonator. Hardware circuits may provide high-speed fault monitoring and processing. For example, violations of current and voltage set points and amplifier half-bridge (H-bridge) shoot-through may need to be detected within less than one millisecond in order to prevent catastrophic failures of the source electronics.
On a medium timescale, the amplifier controller may monitor the impedance of the source coil and may react to out-of-range impedance conditions in less than 500 ms. For example, if the impedance is too inductive and out-of-range, the efficiency of power transfer may be reduced and the system may turn down or shut down to prevent components from heating up and/or to prevent inefficient energy transfer. If the impedance is inductive, but low and out of range, the system may react as when the resonator is too inductive, or it may react differently, or more quickly, since transitioning from an inductive load to a capacitive load may damage the source electronics. In exemplary and non-limiting embodiments, a hardware circuit may be used to sense if the load the amplifier is driving has become capacitive and may over-ride other slowed control loops and turn down or shut down the source to prevent the unit from becoming damaged.
In exemplary and non-limiting embodiments, system-level power requirements may be determined on the vehicle side and may be fed back from the ADP to the ASP. Over I2C, the ASP may request that the amplifier controller increment or decrement the power from the amplifier for example. The bandwidth of the power control loop may be limited by the latency in the wireless link and by the latency in communication between the ADP and the battery manager.
In exemplary and non-limiting embodiments, a rectifier may convert the AC power received from the device resonator to DC output power for the vehicle, vehicle battery or battery charger. A monitoring circuit for the rectifier output power, current and or voltage, as well as for the battery charge state may provide the feedback for closed-loop control of the system's power transfer. The rectifier may control the output voltage to maintain it within the range desired by the battery management system. Additional fault monitoring and an interface to vehicle charging control processes may be provided by the ADP.
In an exemplary embodiment, a rectifier module may comprise a full-bridge diode rectifier, a solid-state switch (e.g. double pole, single throw (DPST) switch), and a clamp circuit for over-voltage protection. Under normal operation, the full-bridge rectifier may send DC power through the closed switch and the inactive clamp circuit to the battery system. If the battery system needs more current, it may request it from the ADP which may forward the request to the ASP on the source side. If the battery needs less current, the corresponding request may be made. The speed with which these conditions must be detected, communicated, and acted upon may be determined by how long the system can safely operate in a non-ideal mode. For example, it may be fine for the system to operate in a mode where the wireless power system is providing too little power to the vehicle battery, but it may be potentially hazardous to supply too much power. The excess power supplied by the wireless source may heat components in the resonator, clamp circuit and/or battery charge circuit. The speed of the feedback control loop may need to be fast enough to prevent damage to these components but may not need to be faster than that if a faster control loop is more expensive, more complex, and/or less desirable for any reason.
In exemplary and non-limiting embodiments, a switch and a clamp may provide vehicle-side protection against potential failure modes. For example, if the vehicle side enters its Anomaly state, it may notify the source which may subsequently enter its Anomaly state and may turn down or shut down the source power. In case the wireless link is down or the source is unresponsive, the switch in the rectifier may open to protect the battery system.
In an exemplary embodiment, an ADP could enter its Anomaly state in several ways. A few examples include:

- The battery manager requests an emergency disconnect
- The voltage clamp circuit is active for more than 3 seconds (or some set period of time, potentially user settable and reconfigurable)
- The wireless communications link is down
- The ADP does not update the watchdog timer in the rectifier controller
- A temperature, voltage, current, or other error-condition set point is violated.

In an exemplary and non-limiting embodiment of a charging engagement, control-system information may flow across the following interfaces:

- ASP-ADP: Wireless interface between the Application Source Processor on the source side and the Application Device Processor on the vehicle side.
- ASP-Laptop: Wireless interface used to send a webpage with source diagnostic information that can be displayed on a laptop for demonstration, system configuration, and debug purposes.
- ADP-Laptop: Wireless interface used to serve a webpage with device diagnostic information that can be displayed on a laptop for demonstration and debug purposes.
- ASP-AmpCon: an I2C interface between the ASP and the amplifier controller.
- ADP-RectCon: an I2C interface between the ADP and the rectifier controller.

In exemplary and non-limiting embodiments, the first interface (ASP-ADP) may be used to exchange the messages needed to support the exemplary Sequence Diagram shown in FIG. 5. It may be that standardization activities will specify certain wireless communications protocols, such as the IEEE 802.11p protocol and/or Dedicated Short Range Communications (DSRC) using a licensed band at 5.9 GHz. In exemplary and non-limiting embodiments that comply with standards, it may be that only certain wireless communications protocols will be supported by and used to implement the wireless power system controls. In exemplary and non-limiting embodiments not governed by standards, both known and proprietary wireless communications protocols may be supported by and used to implement wireless power system controls. In an exemplary embodiment, a reconfigurable EV wireless power transfer system has been demonstrated using the IEEE 802.11b unlicensed band (Wi-Fi) to implement the system control commands and communication.
In exemplary and non-limiting embodiments, the second and third diagnostic interfaces may be for running demonstration purposes and to provide diagnostic information in an easily accessible format. The connections with the laptop may also use 802.11b. A Wi-Fi enabled router may be required for simultaneous support of wireless connections for the ASP-ADP, ASP-Laptop, and ADP-Laptop. For demonstrations that only require the ASP-ADP connection, an 802.11b peer-to-peer connection could be used.
In exemplary and non-limiting embodiments, the fourth and fifth interfaces may be between the ASPs, other system controllers, and data loggers. Other system controllers may be implemented in physically distinct microcontrollers as described in the exemplary embodiment, or they may be co-located in the same ASPs.
Some example interactions amongst the ASP, ADP, controllers and FOD detectors are described below. These are just some of the example interactions, but in no way are the interactions contemplated by this invention limited to only the examples given below.
In an exemplary embodiment, an Application Source Processor (ASP) may be a microprocessor that holds the state information for the source side of the reconfigurable EV wireless power transfer system. Physically, it may be implemented in a PIC-32 microcontroller. The software running on the ASP may execute the state transitions described previously, as well as the wireless communication with the vehicle side and potentially with the diagnostic laptop (if present). It is anticipated that users may modify or replace the software on the ASP and still operate the reconfigurable EV wireless power transfer system. Functional interfaces to the Application Source Processor may include, but may not be limited to:

- Wi-Fi link for communicating with the vehicle's ADP and for a diagnostic display for user demonstrations, diagnostics and/or customization (iPAD or laptop)
- Serial Peripheral Interface (SPI) serial-link over Ethernet on a 2.4 GHz RF link for communicating with the vehicle's ADP
- Hardware support for Universal Asynchronous Receiver/Transmitter (UART) serial-link over Ethernet on a 2.4 GHz RF link for an alternative method of communicating with the vehicle's ADP
- Interface to amplifier controller
- I²C for commanding and receiving status information
- Interrupt for high-priority tasks (e.g. FOD detection, source or vehicle anomaly)
- Bi-directional watchdog/heartbeat signal
- FOD detection interface
- Metal object detector
- Temperature sensors
- Living being sensor
- System process interlock inputs-used for higher-level controllers that may need to shut down the source suddenly.
- I²C interface to source side PIM (PCB Information Memory with a unique identifier (UID), configuration settings, etc.)

In an exemplary embodiment, an ASP may have a Wireless Communications Link Interface. For example, the source-side ASP may communicate with the vehicle-side ADP over a wireless communication link. The wireless protocol may be implemented using TCP/IP over a 2.4 GHz Wi-Fi link. The RF module may be IEEE Std. 802.11b compatible with a 4-wire SPI interface to the ASP.
In an alternate exemplary embodiment, a communication interface using the ASP serial UART port may be available as an option. The serial port might interface to an external wireless module to support the link. A standard UART interface may provide the flexibility to use any particular wireless protocol that a user may want.
In an exemplary embodiment, there may be an interface between the ASP and the amplifier controller. An amplifier controller may provide low-level control of the source electronics, while the ASP may provide high-level control and may be responsible for the execution of the overall system charging cycle. The interface to the amplifier controller may be presented as a set of control and status registers which may be accessible through an I²C serial bus. Such an arrangement could support user customization of the control algorithms.
In an exemplary embodiment, there may be an interface between an ASP and a FOD detection subsystem. The ASP may be able to receive preprocessed digital data from a FOD processor. A FOD processor may be designed to perform signal conditioning and threshold detection for the various types of sensors connected to it. Upon detection of FOD, the FOD processor may interrupt the ASP and transmit the FOD decision-circuit results. The ASP may then take appropriate action (e.g. shut down the power, go to a low-power state, issue a warning, etc.) The FOD processor may also transmit the pre-decision signal-conditioned data in digital form to the ASP so that soft decision algorithms that use other information can be implemented in the ASP.
In an exemplary embodiment, there may be an interface between an ASP and a System Interlock subsystem. An interlock interface may consist of a set of optically coupled digital inputs which may act as system enables. The interlocks may be externally generated signals which may be asserted to turn on the system. The interlocks may also be able to be used by the user to shut down the system on command. The systems and signals that feed the external interlock signals (shutdown switch, additional FOD detection, infrastructure fault detection, etc.) may be application specific.
In an exemplary embodiment, there may be an interface between an ASP and a Positioning and Alignment Interface. A positioning and alignment interface may communicate data from a vehicle alignment and positioning sensor to an ASP to determine whether sufficient wireless power transfer efficiency may be achieved given the measured relative position of source and device resonators. If the resonators are not sufficiently well aligned, the ASP may communicate to the device ADP and instruct the system to generate a message to the driver that the vehicle needs to be repositioned and to inhibit system turn-on until proper positioning is established.
In exemplary and non-limiting embodiments, there may be an interface between an ASP and a Diagnostic/Debug subsystem. For the purposes of demonstrations, customization, and testing, a diagnostic/debug interface may be available across a wireless link between an ASP and a laptop, or tablet, or smartphone or any other processing unit that preferably comprises a display. In some exemplary and non-limiting embodiments, the wireless communications connection may be through a dedicated Wi-Fi network. In exemplary and non-limiting embodiments, the interface may allow a laptop, or other external controller, to put the EV wireless power transmission system in a diagnostic and/or customization mode where preset interlocks may be over-ridden and state changes may be forced onto the ASP.
In exemplary and non-limiting embodiments, this interface may also allow a laptop, or other external controller, with a Wi-Fi capability to access the ASP. For example, the ASP may be capable of streaming state information to the laptop which may store it in a log file. Parameters that can be stored in the log file may include:

- Time-stamped events such as state changes, messages passed, messages received
- Measured voltages, currents, temperatures, and impedances that are being compared to set points by the ASP or amplifier controller.
- Configuration information such as software/firmware versions, hardware IDs, etc.
- The log file should be able to be viewed on the laptop and incorporated into a spreadsheet for later analysis.

In exemplary and non-limiting embodiments, an Application Device Processor (ADP) may be a microprocessor that holds the state information for the vehicle side of an EV wireless power transfer system. Physically, it may be implemented in a PIC-32 microcontroller. In exemplary and non-limiting embodiments, the software running on the ADP may execute the state transitions described previously, as well as the wireless communication with the source side and the diagnostic laptop, or other external controller. Users may modify or replace the software on the ADP to customize the operation and control of an EV wireless power transfer system.
In exemplary and non-limiting embodiments, functional interfaces to the Application Device Processor may include but may not be limited to:

- Controller Area Network (CAN) Bus implemented on the physical layer (PHY) on the device side for use with vehicle communication, diagnostic equipment, and/or measurement and or monitoring equipment
- Serial-link over Ethernet on a 2.4 GHz RF link for communicating with the Source ASP
- Wi-Fi to a diagnostic display for user demonstrations and/or customizations (iPAD or laptop)
- Interface to a rectifier controller
- I²C for commanding and receiving status information
- Interrupt for high-priority tasks (e.g. FOD detection, vehicle anomaly)
- Bi-directional watchdog/heartbeat signal
- System process interlock inputs used for higher-level controllers on a vehicle that may need to disable the charging cycle.
- I²C interface to Device side PIM (PCB Information Memory with UID, configuration settings, etc.)

In some exemplary and non-limiting embodiments, there may be an interface between an ADP and a CAN Bus. In some exemplary and non-limiting embodiments, the ADP may include a CAN bus interface. In exemplary and non-limiting embodiments, software running on an ADP may be augmented by a user to support a CAN bus interface even if the as-designed and/or as-delivered EV wireless power transfer system did not include this functionality.
In exemplary and non-limiting embodiments, a vehicle-side Application Device Processor may have a Wireless Communications Link Interface. For example, a device-side ADP may communicate with the source-side ASP over a wireless communication link. The wireless protocol may be implemented using TCP/IP over a 2.4 GHz Wi-Fi link. The RF module may be IEEE Std. 802.11b compatible with a 4-wire SPI interface to the ADP.
In exemplary and non-limiting embodiments, there may be an interface between an ADP and a rectifier controller. The ADP may communicate with the rectifier controller over an interface that may be similar to the one between the ASP and the amplifier controller. A rectifier controller may provide low-level control of the device electronics, while the ADP may provide high-level control and may be responsible for the execution of the overall system charging cycle. The interface to the rectifier controller may be presented as a set of control and status registers which may be accessible through an I²C serial bus. Such an arrangement could support user customization of the control algorithms. The interface may also consist of, an Interrupt Request input and a set of uni-directional watchdog/heartbeat outputs.
In an exemplary embodiment, there may be an interface between an ADP and a Positioning and Alignment Interface. A positioning and alignment interface may communicate data from a vehicle alignment and positioning sensor to an ADP to determine whether sufficient wireless power transfer efficiency may be achieved given the measured relative position of source and device resonators. If the resonators are not sufficiently well aligned, the ADP may communicate to the source ASP and instruct the system to generate a message to the driver that the vehicle needs to be repositioned and to inhibit system turn-on until proper positioning is established.
In exemplary and non-limiting embodiments, there may be an interface between an ADP and a System Interlock subsystem. This interface may be analogous to that described between an ASP and a System Interlock subsystem. It could be used by the battery manager to force a shutdown of the EV wireless power transfer system. For example, if the interlock is de-asserted, the ADP may enter its Anomaly state and may demand that the source shut down immediately and may open the switch in the rectifier circuit. In the case of an unresponsive source or an interrupted wireless communications link, the ADP may open the switch within 3 seconds, or an appropriate period of time, and communicating a command that the source shut down.
In exemplary and non-limiting embodiments, there may be an interface between an ADP and a Diagnostic/Debug subsystem. For the purposes of demonstrations, customization, and testing, a diagnostic/debug interface may be available across a wireless link between an ADP and a laptop, or tablet, or smartphone or any other processing unit that preferably comprises a display. In some exemplary and non-limiting embodiments, the wireless communications connection may be through a dedicated Wi-Fi network. In exemplary and non-limiting embodiments, the interface may allow a laptop, or other external controller, to put the EV wireless power transmission system in a diagnostic and/or customization mode where preset interlocks may be over-ridden and state changes may be forced onto the ADP.
In exemplary and non-limiting embodiments, this interface may also allow a laptop, or other external controller, with a Wi-Fi capability to access the ASP. For example, the ASP may be capable of streaming state information to the laptop which may store it in a log file. Parameters that can be stored in the log file may include:

- Time-stamped events such as state changes, messages passed, messages received
- Measured voltages, currents, temperatures, and impedances that are being compared to set points by the ADP or rectifier controller.
- Configuration information such as software/firmware versions, hardware IDs, etc.
- The log file could be viewed on the laptop and dumped into excel for later analysis.

In exemplary and non-limiting embodiments of EV wireless power transfer systems, an amplifier controller may provide low-level control to a Power Factor Corrector (PFC) and a switching amplifier. The interfaces between an amplifier controller and other system components may include, but may not be limited to:

- Interface to Application Source Processor
  - I²C
  - Interrupt
  - Bi-directional Heartbeat/Watchdog
- PFC Hardware control interface
- Amplifier hardware control interface
- System critical interlock inputs
- System On/Off

In exemplary and non-limiting embodiments of EV wireless power transfer systems, a rectifier controller may provide high speed monitoring of rectifier power and system critical fault control. The interfaces between a rectifier controller and other system components may include, but may not be limited to:

- I²C interface to Application Device Processor
  - I2C
  - Interrupt
  - Bi-directional Heartbeat/Watchdog
- Rectifier hardware control/status interface
- Fault indicators such as over current, over voltage, over temperature, clamp circuit activated, etc.
- Device side system critical interlock inputs.

An reconfigurable EV wireless power transmission system may be partitioned into notional subsystems so that the interactions between subsystems may be studied and design decisions made be made as to which control functions and set-points may be customizable by a use while still ensuring safe, efficient and reliable performance of the system. One method to analyze the system performance impact of allowing customization and/or reconfigurability of the control architecture and/or algorithms and/or set-points is to perform a Failure Mode Effects Analysis (FMEA). A preliminary FMEA may comprise a prioritized listing of the known potential failure modes. FMEA may need to be an on-going activity as new system failure modes are identified.
In exemplary and non-limiting embodiments, an FMEA process that scores potential failure modes in a number of categories may be used to identify the severity of certain failure scenarios. Categories that may be used to identify customizable parameters may include, but may not be limited to

- Severity (1-10): If the failure mode occurs, how severe (SEV) is the impact to system functionality, performance, or safety? A score of 10 indicates a major hazard and a score of 1 indicates a minor loss of performance or functionality.
- Likelihood (1-10): How likely is the failure to occur? A 10 indicates almost certain occurrence while a 1 indicates a very remote chance of occurrence (OCC).
- Undetectability (1-10): How likely is it that the failure will be detected (DET) and reacted to by the system during operation? A 10 indicates that the control architecture is very unlikely to detect the failure while a 1 indicates almost certain detection.

In exemplary and non-limiting embodiments, the potential failure modes may be prioritized according to their Risk Priority Number (RPN)—which is merely the product of their three category scores.
While the invention has been described in connection with certain preferred exemplary and non-limiting embodiments, other exemplary and non-limiting embodiments will be understood by one of ordinary skill in the art and are intended to fall within the scope of this disclosure, which is to be interpreted in the broadest sense allowable by law. For example, designs, methods, configurations of components, etc. related to transmitting wireless power have been described above along with various specific applications and examples thereof. Those skilled in the art will appreciate where the designs, components, configurations or components described herein can be used in combination, or interchangeably, and that the above description does not limit such interchangeability or combination of components to only that which is described herein.
All documents referenced herein are hereby incorporated by reference.

Claims

1. A wireless energy transfer system with a segmented control architecture, the system comprising:

a wireless energy transfer system coupled to a primary controller; and

a user configurable secondary controller in communication with the primary controller;

wherein the primary controller performs essential control functions for the wireless system.

2. The system of claim 1, wherein the essential control functions of the primary controller comprise maintaining wireless energy transfer operating safety limits.

3. The system of claim 1, wherein the essential control functions of the primary controller comprise monitoring and controlling the voltage and current on energy transfer components.

4. The system of claim 1, wherein the user configurable secondary controller allows adjustment of at least one non-safety critical parameter of the system.

5. The system of claim 1, wherein the primary controller and the user configurable secondary controller are each physically implemented on the same hardware.

6. The system of claim 4, wherein the user configurable secondary controller is configurable to adjust a maximum output power of the wireless energy transfer system.

7. The system of claim 4, wherein the user configurable secondary controller is configurable to adjust a frequency of the wireless energy transfer system.

8. The system of claim 4, wherein the user configurable secondary controller is configurable to adjust the security of the wireless energy transfer system.

9. The system of claim 1, wherein the primary controller and the user configurable secondary controller are each virtual controllers implemented on the same processor.

10. The system of claim 1, wherein the primary controller and the user configurable secondary controller are each separate processors.