| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Paul, The original study group, that included most of the vendors for all the products that use external power supplies, was specifically aimed in this directed as shown in the PAR. None of this has changed in any way except the power limit has been raised for good reason. With the <240Watt limit, almost all portable/mobile devices are included now. This is intended to be UNIVERSAL. The focus has been on laptops, printers, peripherals for now. I do not believe that we have lost sight of the more general goal. The discussion topics seem to be centered in the correct power range. It is most likely the case that with a common power system available, it will be easier to include in new designs than to create yet another incompatible external power supply. Some will to it anyway. There will always be exceptions, like the 1KW audio amps. Adding a remote turn on/off mechanism expands the capability and goes farther to be more power efficient in the overall system. In my mind the biggest problem is a way to make the system secure enough for large deployment. I have ideas and I am sure others will also. Respectfully; Bob Davis Summit Computer Systems, Inc. bobd@xxxxxxxx 408.857.1273 From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Paul Panepinto Hello Leonard: Good question. In the short-term, one scenario might be an integrated AC power strip with DC power outlets. That way, the power strip can shut down power to the ports that should be shut down when the primary Sink gets shut down. Much longer term, perhaps televisions, DVD and Blu-Ray devices, stereos and most electronic equipment will stop including AC-DC power supplies inside of them. Why not have external DC power hubs that endure instead of internal AC-DC power supplies inside of them? Why not move power outside of those products, making them lighter in weight and able to run cooler? What do you think? Regards, Paul Panepinto UPAMD Power Subgroup Chair (970) 461-3077 From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Leonard_Tsai@xxxxxxxxxx I agree with Bob that this is a great concept to consider. In long term view, I hope that other devices like BD, TV, etc. in Stephen’s scenario, will all adopt UPAMD spec. but these devices typically are connected to AC socket directly, even with AC pass-through socket. How do we envision such usage? Leonard From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Bob Davis Paul, The RequestShutDown for the calling device is already in the protocol as Power request with a level of 0. Power level 1 is communications power only. This functionality will need to be optional. Devices that do not implement this capability will just ignore any such requests/commands. The ability to control specific other devices is, I believe, the point of Steve’s suggestion/request. I believe this has great merit and we need to figure out how to do it. Needed elements: Ability to identify devices by a unique identifier. Ability to message that specific device. Ability for that device to make determination of conditions for shutdown. Ability to restart that device when needed by any resource. Security for the transaction. A printer is a case where it may be used by the laptop, but could also be used by other devices on the power system. The relationship between the requestor and the device may not be unique. Many device could be using the printer. The printer would need to decide who it is servicing, possibly many devices, and if it can shut down. It may have its own service queue. Unique Identifier: This is the reason for the EUI. This will work even with many like devices. Looking up vendor/model/serialnumber would be hard to keep in a list of these properties as a queue. Specific device: We will need to build a tree/grid of all devices in the local environment. This could be a small as 2 for the simple adapter/sink connection or more elaborate for multi-output adapters with hub/adapters and other power sources such as solar/wind/etc. This mapping will provide the path to any element and the identifier for that element. We have the message structure for this. Conditions for shutdown: Each device capable of this remote control will need to keep a list of devices being services or logical attachments. It would be capable of shutting down as long as the logical attachment list has become empty. Ability to restart: Turn on only requires the addition to the logical attachment list of the device. This list now may be one long or longer. This could work to bring the entire system on line with messages to each effected, or dependent, device. Discovery of new devices will need to be addressed. Security: As Piotr pointed out, we would like to have the ability to ensure a rogue device, possibly with malicious intent, could cause a very disruptive shutdown, of power up for unauthorized access. This would need to be an additional optional feature. A possibility is to equip each capable device with an a PKE set into the device and have some of the power messages, as well as other messages, encrypted. As the messages are short and infrequent is should be less demanding computationally, but stills requires the storage space. A possibility would be something like the very well known SSH system. This could lead to 3 levels of implementation: 0 – no implementation – it is on or off 1 – simple command set with physical security being used 2 – a more secure system with encrypted messages. The design and the standard would need to allow, and work with, a mixed set. I believe this is a great concept and should be part of what we are doing. What will need to be in the standard to allow it to be implemented? Respectfully; Bob Davis Summit Computer Systems, Inc. 408.857.1273 From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Paul Panepinto Hello Stephen: In my view, this is application level functionality outside the scope of the UPAMD spec. What is important is that UPAMD provides primitives so that any vendor wishing to implement this clever on/off energy-saving feature can do so. That said, we may want to consider a message type RequestShutDown. While we can clearly implement a scheme where the power hub shuts down power to peripheral devices when the PC shuts down without the need for exchanging messages, it would be nice to be more collaborative to give the peripherals a more graceful shutdown option or to refuse shutdown if needed. Best regards, Paul (970) 461-3077 Skype: ppanepinto Green Plug - Digital Power From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of stephen.sedio@xxxxxxxxxxx
|