[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ocpp] OASIS OCPP: Use Cases for show message on Charge Point wanted
Sergiu identifies a number of very good points, to which I would like to add some further points on this subject that have been discussed in various fora, at various times in the past.
Taking a slightly wider picture, there are two broad visual display hardware class cases that have overlap, but also have significant differences in possible use case scope:
1. “Small” displays, commonly encountered on less sophisticated, low power, long-stay charging equipment.
· Character mode display devices
o Limited character set
§ 128/256 element (usually fixed) character set (e.g. ASCII/ANSI)
o Limited display width (expressed in character columns; very often as low as 20)
o Limited display rows (expressed in lines, very often as low as 2)
o Monochrome display
For these types of display, it will be essential for the characteristics/constraints to be communicated by the Charge Point to the Central System using the Device Model, as part of the enrolment/inventory mechanism.
Given the wide variation of these constraints between charging equipment, it will most likely be necessary for the format and content of the display text to be decided at the controlling Central System (either automatically, or with prior human assistance (via templates, etc.).
Because of the often very limited display “real estate”, information of a supplementary/secondary nature will often need to be alternated with “primary” information (charging progress status, energy transferred, cost, etc.) as part of a repeating cycle of display “frames”, each of whose content and display duration are individually controllable by the Central System.
To support the display of locally measured/computed information in the case of offline operation (e.g. charging duration, delivered kWh, locally computed cost), it is desirable that some standardized text content template & variable substitution placeholder mechanism be defined.
2. “Graphic” displays, most often encountered on more sophisticated (and increasingly high-power) charging stations.
These are already common on complicated high power multi-standard charging equipment, where they are now typically used primarily/solely to convey operating instructions. They typically feature pixel resolutions of at least VGA (640 x 480), colour, and often touch screen, or edge aligned multi-function UI input buttons.
With products and plans from various EV and charging equipment vendors for charging rates of up to 300kW and more in coming years, there is an increasing likelihood that the EV driver may remain in the vehicle for (much of) the duration of the shorter charging time, and consequently there will be a requirement for more sophisticated information communication (from possibly large screens) that is often incidental to the vehicle recharging activity: e.g. cross-selling & up-selling of linked products/plans/services, general or site specific advertising, etc.
We had a similar subject for some time (we did not got a solution).
The following requirements for a custom message was relevant:
1. The message should fit into one sub-screen (a list of sub-screens displayed during one state in a cycle. The cycle relates as long as the state persist)
2. The message should support different screen levels (Single line B&W, multiline B&W, multiline Color etc. )
3. The message should support graphic elements (from your example a Santa Claus picture)
4. The message should support simple multiline formatting elements (like CSS: Size, Font, Color etc.)
5. The message should support different languages (Unicode?)
6. The message should include the minimum display time in a cycle
7. The message can include the overlay priority (display on top of all screens or between the screens at the cycle end)
8. The message can include the maximum display time in a cycle
9. The message can include a validity period or number of cycles
10. The message can include the charging point state when is should be displayed (ex. only in idle)
As examples i would add:
- Display bonus information
- Display personalized greetings
Hope this can be helpful for you.
Mit freundlichen Grüßen / Kind regards
Von: email@example.com [mailto:firstname.lastname@example.org] Im Auftrag von Robert de Leeuw
There was an idea for a CR about sending a message/text to a Charge Point that should be displayed on the Charge Point if it has a display.
Are there companies in this TC with use cases for this? Requirements?
Can you please provide these?
* ** *** ** * ** *** ** * ** *** ** *
* ** *** ** * ** *** ** * ** *** ** *