2.3.4.1 Definitions of Categories
(D): explains, that CAT C should include CAT B
(OICA): As long as the other CATs are not finally defined we should leave it open
(D): if you are steering manually, CAT C, CAT D and CAT E makes no sense
(NL): shares D comments
(S): has currently no opinion
(UK): is ok with D comments
(F): Keep CAT C and CAT D without including CAT B
(D): describes the problem, that a CAT C system (without CAT B) does not know, when to start the manoeuvre and when the lane change manoeuvre is over.
(OICA): Concepts for systems without CAT B are in work.
(EC): we work currently on CAT E. So we should define the requirements for CAT E and come back to the definitions when defining these CATs.

2.4.8.1 Definition of Motorway
Definition of the motorway was moved to the requirement section

2.4.8.6 "Specified maximum speed Vsmax "
proposed amendment was agreed

2.4.8.7 " Specified minimum speed Vsmin "
proposed amendment was agreed

2.4.8.8 " Specified maximum lateral acceleration aysmax"
(OICA): is the wording correct?

Homework: D, J to rework definition considering emergency cases

2.4.8.10 " Conditions for operation "
proposed amendment was agreed

2.4.8.11 " System boundaries "
proposed amendment was agreed

2.4.8.16 " Protective braking "
(OICA): proposed to wait until the requirements are defined, but in principle ok.
proposed amendment was agreed

2.4.8.17 " Data Storage System for ACSF (DSSA) "
(SE): is here the risk, that we are doing something separate, which is already in work in another group (e.g. ITS/AD)? In general he agreed to the need of such a feature.
(NL): should be located in a horizontal regulation. Regulation 79 is the wrong place for this.
(C-D): this is also necessary to “protect” the driver
(NL): here we have also to consider data protection and again, this has nothing to do with Regulation 79.
(C-D): Shall we wait for the results of the ITS/AD group?
(C-J): DSSA is a strong request of Japan, otherwise Japan cannot support this ACSF-Regulation.
(UK): see the need of a DSSA, but not so strong as J. Preferring to include it in the horizontal regulation.
(C-D): Do we have systems (e.g. ACC systems) in the market, where data is recorded?
(OICA): must be checked
(CLEPA): standard systems store only the failures
(SE): EC is looking for a EDR in the future. Why do we need this here for this use? Supports NL to have this in the horizontal regulation.
Conclusion: will be reviewed after discussion the requirements

5.4.3.1 " …termination of control… "
proposed amendment was agreed

5.5.2 " PTI "
(SE): we need to understand, which codes should be used. We should specify this
(OICA): here we should make it simpler as e.g. OBD. The information should only say “working or not”
(C-D): want to know, whether the correct SW version is in the system.

Homework: D to rework considering the SW-version, whether it was amended

(CLEPA): this is already considered in Annex 6
(NL): why is the word “complex” in the wording (“…status of those Complex Electronic Systems…”) ?
(D): to avoid misinterpretation, that this is a complex electronic system
(OICA): is this in line with the EC proposal for PTI? The SW-Version is not part of this.
(UK): PTI does not need to know the SW-Version
(EC): do we need this § at all?

5.6.1.1.3 “driver is overriding
(UK): does this also mean for small steering corrections?
(D): we need a clear interface between driver and the system. There may be also other causes for overriding. Important is, that the driver can always override the system.
(OICA): is this a deactivation or a temporarily inactivation?
(UK): a braking intervention should switch the system off, but also a steering input?
(EC): is the driver is steering manually, we should switch off the function.
(C-J): Steering input of the driver shall deactivate the system. Braking input or others, may deactivate the system.
(D): if the driver is steering manually, a non-deactivation would confuse the driver
(UK): as this is a Level 2 system, hands on is necessary
(EC): supports, that an intervention may deactivate the system
(OICA): we have to consider, what is already in Regulation 79 (5.1.6: “… shall be designed such that the driver may, at any time and by deliberate action, override the function…” )
(D): what leads to overriding or deactivation of the system should be mentioned in the system data.
(C-D): the only oversteering issues are: Braking, steering, accelerating
(F): is the system with or without ACC?
(CLEPA): a CAT E system without ACC is not possible
(D): steering → shall deactivate the system; braking and others → may deactivate the system

Homework: D, UK, OICA to rework

5.6.1.1.4.1 “…maximum lateral acceleration aysmax …”
(EC): why do we need a minimum value
(D): to specify the minimum performance of the system. The system should either reduce the speed in front of a curve or to start a transition at max. 3 m/s²
(SE): are systems able to detect the curves before?
(OICA): the system should be able to know the path of the vehicle
(CLEPA): maybe for trucks and buses the 1 m/s² is too high
(C-D): conclusion: remove the [ ] . To be reconsidered if CLEPA has more input.

5.6.1.1.6 “…control the movements of the vehicle…”
(F): proposed to add longitudinal to the lateral movement
(C-D): remove “lateral” from the wording and do not add “longitudinal”.
proposed amendment was agreed

5.6.1.1.7 signals for the driver
(OICA): leave “manual” in the wording (and not “standby”)
(C-D): asked OICA to make a clear definition of the different modes.
(OICA): we should only differ between “automatic” and “manual”

Homework: OICA provide a definition for “active”, “standby”, “failure” and “OFF” mode

5.6.1.1.8 “…monitor…a minimum range to the front…”
(NL): obstacles should also be detected
(SE): what about (big) animals?
(C-D): is it necessary to specify this?
(NL): yes!
(EC): mentioning the conditions only in the test requirements is not enough

Homework: NL, SE, OICA to rework considering obstacles, animals and distance values(?) – if necessary

Homework: D to rework considering VUT

5.6.1.1.8.3 " range to the left and to the right "
proposed amendment was agreed

5.6.1.1.9 " …vehicle shall fulfil the tests… "
proposed amendment was agreed

5.6.1.2.1 Any lane change manoeuvre shall be initiated only if:

Homework: UK to rework considering pedestrians, [ ] and LHD/RHD traffic.
To be moved partly to 5.6.1.1.9/10?

5.6.1.2.2 “…direction indicator…”
proposed amendment was partly agreed

Homework: EC to rework

5.6.1.2.3 “…system detects an imminent critical situation…”

Homework: UK to improve the wording

5.6.1.2.4 “…prior and after a lane change…”

Homework: UK to improve the wording

5.6.1.2.5 “…sudden unexpected event…”

Homework: D to improve the wording (separating lane change /emergency)

5.6.1.2.6 Driver availability recognition system

Presentation of SE and NL (ACSF-05-06)

(C-D): the infotainment system can be used to detect drivers activity, but also something else…
(NL): target of this proposal is, that the infotainment system is mounted, that the driver can look directly to the front.
(C-D): the driver is still fully responsible. Could it be a solution, that e.g. a head up display is used? It is to consider, that design restrictive requirements should be avoided.
(NL): monitoring the head direction could also be used.

Presentation of OICA (ACSF-05-10)

(D): supports the OICA approach. Why should we be more stringent as at LKAS => it is not necessary to check every 10s
(C-J): proposals are going in the same direction
(SE): there should be a requirement. To define a recognition system depending on the performance is more complicated. We need studies with sleeping drivers
(F): we should not define something in the regulation, which is maybe not necessary in the future. Target should be, what is required short term. Support new studies.
(C-D): we can add here a lot of things, which are not allowed (e.g. sleeping, alcohol, driving without driver licence). We cannot cover every misuse. We should not overload the system.
(EC): origin wording is a good compromise
(OICA): there must be a balance of the minimum requirements
(D): 4s is the worst case of a drowsy driver. After 4s we have the Minimal Risk Manoeuvre (MRM), which gives the driver more time.
(UK): we are still at Level 2 (not using TV etc.). Sleeping cannot be solved yet.
(SE): we cannot deal with every misuse. Disagree, that the OICA document reflects the Tokyo status. Some kinds of limits should be made (10s, 20s, …)
(D): we have to define different requirements for the different categories. Proposes a compromise.
(CLEPA): an eye recognition system for a high volume production car is currently not available
(F): the proposal of D is a good starting point
(SE): we are not far away from each other

(C-D): Proposal:
the system should include two features:

Comment of the delegates:
(EC): tbd.
(SE): agree to the principles, but only 5 minutes
(F): agree to the principles,
(J): tbd
(NL): agree to the principles 15 minutes are too long
(OICA): good compromise
(CLEPA): good compromise

Homework: NL, SE, D, UK to improve the wording considering the “compromise”

5.6.1.3.1.1 “values for Vsmax , Vsmin and aysmax“
proposed amendment was agreed

5.6.1.4.3 “…driver availability recognition system…”
to be reviewed after rework of 5.6.1.2.6

5.6.1.4.4 “…driver’s seatbelt is unfastened…”
proposed amendment was agreed

5.6.1.4.5 “…other failures than a single sensor failure …”
proposed amendment was agreed

5.6.1.4.6 “…vehicle is fitted with a built-in infotainment system…”
proposed amendment was agreed

5.6.1.6 Protective Braking
(NL): not only road users, also obstacles have to be mentioned
(SE): confirmed NL statement

Homework: D, NL, SE to improve the wording considering decelerations other than braking, end of deceleration requirement, lane change “without risk”, should be equipped with protective Braking, road user, “obstacles”…

5.6.1.7 Data Storage System for ACSF (DSSA)
(C-J): as already mentioned, this is very important for J. It should not be considered as a part of the Event Data Recorder (EDR)
(EC): is protected braking also part of these data?
(C-J): yes
(OICA): there are already other “Geneva-groups” working on this issue, so a coordination is necessary (ITS/AD, GRSG). Data protection has to be considered (movie!)
(C-D): waiting for other groups would cause a delay of 2-3 yrs.
Specifications should be defined:
– Movie: -30 s … +5s when a crash occurs
– other system reactions should be recorded
In a new regulation the result of ITS/AD may be considered
(SE): is not opposing to have it here in this group.
Problem: What is the info we need for a judge? We should go back to the legal people to clarify this before we start activities. Who is the owner of the data?
(UK): we have to have something for the next meeting. What can we take from eCall?
(C-D): What is the minimum set?
(D-TÜV): at eCall no use of the data after more than 13h after the crash is allowed.

Homework: every party (esp. contr. Parties) should clarify their position

Presentation of D (ACSF-05-14)
(D): presented the document as a proposal, how the tests can be extended to the other categories.

(OICA): good overview. We have to check, whether a 1:1 takeover is possible or whether amendments are necessary.
(F): good start, must be checked in detail
(EC): How to handle systems with ACC?
(SE): helpful overview. Requirements for CAT B2 should be similar as CAT E (without overtaking)
(D): confirms SE statement

Presentation of J (ACSF-05-15)
(J): presented the document as a proposal, how the different requirements can be linked to other categories

(C-D): we should first check table for CAT C.

Discussion: how should the CATs be linked together – CAT B1 should not be a ACSF category

(D): CAT B1 should (only) be a system which enables a LKAS system to work continuously
(SE): confirmed D comments
(OICA): there may be systems in different countries, which would like to have single CAT C or CAT D systems
(C-D): is there a Contracting Party who proposes to have a single CAT C or CAT D system?
(F): if there will be systems on the market, we should not prohibit this.
(EC): we have to think about this
(D): CAT C Systems without CAT B makes no sense. D will not support a CAT C system alone.
(OICA): will bring proposals for a single CAT C system the next meeting.
(C-D): Are there concrete Systems in planning, which perform only CAT C?
(F): maybe there will be future systems of CAT C alone. We should not prohibit this. GRRF to decide.
(C-D): shares F opinion, but we have to specify a minimum safety standard.
(OICA): we should take in consideration, that ACSF is not reserved for High-End cars.
(F): cannot agree, that the row for CAT C is marked in “green” (edit.: so it remains yellow)

Current working document will be transferred to a consolidated document.
This document should be used as basis for further amendments!

A “clean” document may be used as an Informal Document for GRRF81.

The group discussed the proposal of OICA (see 3.4.x in ACSF-04-20)
The Manufacturer shall provide the Technical Service authorities with an explanation of the design provisions built into the ACSF so as to prevent unauthorized manipulations of hardware or software.
For the design of these protective measures, the manufacturer may assume that the protection against unauthorized physical access to the vehicle systems is assured by the means defined elsewhere in the UN-ECE regulatory framework or by equivalent means.

(Chair): thinks that a direct reference is necessary
(NL): agreed, that this would be a good proposal. Would be a reference to a safety standard of the SW be necessary?
(SE): Can we wait for a standard developed for SW security, will it not take too long time?
(Chair): The ITS/AD group will follow this issue and will make recommendations
(J-Chair): We should wait for the recommendations, which are expected to be available in 1Q/2016
(EC): supported the statements of the Chairs.