[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [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.
These are usually limited by one (or often many) of the following constraints:
· 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
i. A. Dr.-Ing. Sergiu Tcaciuc
GmbH & Co. KG
D-57399 Kirchhundem / Germany
AG Siegen HR A 6577 Komplementärin / Unlimited Partner:
AMAD Mennekes Holding Verwaltungs-GmbH Siegen HR B 5975
Geschäftsführer / Managing Directors: Walter Mennekes, Christopher Mennekes,
Michael Büenfeld, Christoph Epe, Volker Lazzaro
stellv. Geschäftsführer / Deputy Managing Directors: Jürgen Bechtel, Dietmar Spurk
Von: firstname.lastname@example.org [mailto:email@example.com.
org] Im Auftrag von Robert de Leeuw
Gesendet: Montag, 7. November 2016 17:13
Betreff: [ocpp] OASIS OCPP: Use Cases for show message on Charge Point wanted
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?
An timpeallacht? - Smaoinigh air sula bpriontáileann tú an r-phost seo.
Please consider the Environment before printing this email.
* ** *** ** * ** *** ** * ** *** ** *
Tá an t-eolas sa ríomhphost seo agus in aon chomhad a ghabhann leis rúnda agus ceaptha le haghaidh úsáide an té nó an aonáin ar seoladh chuige iad agus na húsáide sin amháin.
Is tuairimí nó dearcthaí an údair amháin aon tuairimí nó dearcthaí ann, agus ní gá gurb ionann iad agus tuairimí nó dearcthaí ESB.
Má bhfuair tú an ríomhphost seo trí earráid, ar mhiste leat é sin a chur in iúl don seoltóir.
Scanann ESB ríomhphoist agus ceangaltáin le haghaidh víreas, ach ní ráthaíonn sé go bhfuil ceachtar díobh saor ó víreas agus ní glacann dliteanas ar bith as aon damáiste de dhroim víreas.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
Any views or opinions presented are solely those of the author, and do not necessarily represent those of ESB.
If you have received this email in error please notify the sender.
Although ESB scans e-mail and attachments for viruses, it does not guarantee that either is virus-free and accepts no liability for any damage sustained as a result of viruses.
* ** *** ** * ** *** ** * ** *** ** *