WO2017066829A1

WO2017066829A1 - System and method for controlling access to a crest area

Info

Publication number: WO2017066829A1
Application number: PCT/AU2016/050980
Authority: WO
Inventors: Joseph Glynn
Original assignee: Caterpillar Of Australia Pty Ltd
Priority date: 2015-10-19
Filing date: 2016-10-19
Publication date: 2017-04-27
Also published as: AU2015243312A1

Abstract

Described herein is a computer processing system (114) for controlling autonomous vehicle access to a crest (104). The computer processing system (114) is configured to receive a crest access request from a vehicle (108), determine a relevant operator identifier associated with the vehicle (108), and determine whether a current access number associated with the relevant operator identifier is less than a maximum access number associated with the relevant operator identifier. In response to determining that the current access number is less than the maximum access number a permission granted message is communicated to the vehicle (108) and crest access data is updated to record that an additional vehicle (108) associated with the relevant operator identifier is currently accessing the crest (104).

Description

System and method for controlling access to a crest area

Technical Field

[001] The present disclosure relates to systems and methods for controlling access to a crest area of a mining worksite. Background

[002] The terrain of open-cast mine sites typically includes various crests. For example, benches of a mine each have a crest beyond which the bench face drops-off abruptly.

[003] Crests can be of significant height and as such operations performed on and around crests need to be carefully controlled. This is particularly the case where vehicles are operating autonomously on or around a crest area.

Summary

[004] Described herein is a computer processing system for controlling autonomous vehicle access to a crest, the computer processing system comprising: a computer processing unit; computer readable memory in communication with the computer processing unit, the computer readable memory storing crest access data comprising one or more operator identifiers and defining, for the or each operator identifier, a maximum access number and a current access number, the maximum access number defining a maximum number of vehicles associated with the operator identifier permitted to concurrently access the crest and the current access number defining a number of vehicles associated with the operator identifier that have currently been granted permission to access the crest; a communications interface in communication with the computer processing unit; and instructions executable by the computer processing unit to cause the computer processing system to: receive, via the communications interface, a crest access request from a vehicle; determine a relevant operator identifier associated with the vehicle; read the crest access data to determine whether the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier; and in response to determining that the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier: operate the communications interface to communicate a permission granted message to the vehicle; and update the crest access data to record that an additional vehicle associated with the relevant operator identifier is currently accessing the crest.

[005] Also described herein is a vehicle configured to operate autonomously in a crest area, the vehicle configured to: detect an approach towards a crest located in the crest area; in response to detecting the approach towards the crest, operate a communications interface to communicate a crest access request to a control system; in response to not receiving a permission granted message from the control system, not approaching the crest; and in response to receiving a permission granted message from the control system: approach the crest; and record, in computer readable memory, a permission expiry time associated with the permission granted by the permission granted message.

[006] As used herein, the term "comprises" (and grammatical variants thereof) is used inclusively and does not exclude the existence of additional features, elements or steps.

Brief Description of the Drawings

[007] Various aspects and features will be described with reference to the following figures which are provided for the purposes of illustration and by way of non-limiting example only. [008] Fig. 1 is a pictorial illustration of part of an open-cast mining worksite;

[009] Fig. 2 is a block diagram of a control centre computer processing system and a vehicle computer processing system; [010] Fig. 3 is a flow diagram illustrating a computer implemented method for processing a crest access request;

[011] Fig. 4 is a flow diagram illustrating a computer implemented method for processing a relinquish request;

[012] Fig. 5 is a flow diagram illustrating a computer implemented method for expiring a crest access;

[013] Fig. 6 is a flow diagram illustrating a computer implemented method for processing a renew request;

[014] Fig. 7 is a flow diagram illustrating a computer implemented method for requesting access to a crest;

[015] Fig. 8 is a flow diagram illustrating a computer implemented method for relinquishing access to a crest;

[016] Fig. 9 is a flow diagram illustrating a computer implemented method for requesting renewal of crest access;

[017] Fig. 10 is a flow diagram illustrating an alternative computer implemented method for processing a crest access request;

[018] Fig. 1 1 is a flow diagram illustrating an alternative computer implemented method for processing a relinquish request;

[019] Fig. 12 is a flow diagram illustrating an alternative computer implemented method for expiring a crest access; and

[020] Fig. 13 is a flow diagram illustrating an alternative computer implemented method for requesting access to a crest. Detailed description

[021] Fig.1 provides a partial depiction of part of an open-cast mining worksite 100. The area depicted includes a horizontal or substantially horizontal surface 102 such as a bench. One side of surface 102 is defined by a crest 104 where the surface 102 transitions to a face 106 (the face 106 dropping downwardly away from the surface 102 until it reaches a lower surface such as another bench or pit floor).

[022] During mining operations vehicles 108 traverse and/or perform work on surfaces such as 102. At times these operations require vehicles 108 to approach the crest 104. Given the potential drop over the crest 104, activity near the crest 102 needs to be performed carefully.

[023] Worksite operations are typically overseen and managed from one or more control centres 1 10 A control centre such as 1 10 may be located at the worksite 100 or at a remote location. To assist in monitoring operations, the worksite 100 is provided with various fixed position sensors 1 12 (e.g. video cameras or other sensors) which monitor the worksite 100 and feed data back to the control centre 1 10.

[024] Control centre 1 10 is provided with at least one (and often multiple) computer processing systems indicated generally by 1 14. Control centre computer processing system(s) 1 14 is/are used in overseeing and managing the operations of the worksite 100. [025] Each vehicle 108 is also fitted with at least one (and often several) computer processing systems, indicated generally by 1 16. A vehicle computer processing system 1 16 operates to control vehicle operations (e.g. for autonomous operation) and/or facilitate operator control of vehicle operations (either directly or remotely). Vehicle computer processing system 1 16 also interfaces with various vehicle sensors, indicated generally by 1 18, which operate to sense data in respect of the vehicle's operation and/or its environment. [026] Figure 2 provides a block diagram of an example control centre computer processing system 1 14 (which, for convenience, will be referred to as the control centre system 1 14) and vehicle computer processing system 1 16 (which, for convenience, will be referred to as the vehicle system 1 16). [027] In the present example the control centre system 1 14 comprises at least one processing unit 204. Processing unit 204 may be a single computational processing device (e.g. a microprocessor, a general processing unit, a graphical processing unit, or other computational device) or a plurality of computational processing devices. Through a communications bus 206 the processing unit 204 is in data communication with computer readable system memory 208 (e.g. a read only memory storing a BIOS for basic system operations), computer readable volatile memory 210 (e.g. random access memory such as one or more DRAM modules), and computer readable non- transient memory 212 (e.g. one or more hard disk drives, solid state drives, flash memory devices and suchlike). Instructions and data for controlling operation of the processing unit 204 are stored on the system, volatile, and/or non-transitory memory 208, 210, and 212.

[028] Control centre system 1 14 also comprises at least one input/output interface 214 which allow the control centre system 1 14 to interface with various input/output devices 216. A wide variety of input/output devices may be used, for example keyboards, pointing devices, touch-screens, touch-screen displays, displays, microphones, speakers, hard drives, solid state drives, flash memory devices and the like.

[029] Control centre system 1 14 also comprises one or more communications interfaces 218, such as a Network Interface Card. Communications interfaces 218 are operated to provide wired or wireless connection to one or more communications networks 220 (e.g. the Internet, a local area network, or a wide area network) and communication with other systems connected to the network 220. Such systems include, for example, vehicles 108 (or the computer processing systems carried thereby) and fixed position sensors 1 12. [030] Communication with the communications network 220 (and other devices connected thereto) will typically be by the protocols set out in the layers of the OSI model of computer networking. For example, applications/software programs being executed by system 1 14 may communicate using one or more transport protocols such as the Transmission Control Protocol (TCP, defined in RFC 793) or the User Datagram Protocol (UDP, defined in RFC 768). Alternative communications protocols may, of course, be used.

[031] By operating the communications interface(s) 218, the control centre system 1 14 can communicate with vehicles 108 operating on the worksite 100 over a network such as 220. This communication enables the control centre system 1 14 to send control messages and data to a vehicle 108, for example to update current assignments and/or worksite information and/or or to remotely control a vehicle 108. This communication also enables the control centre system 1 14 to receive messages/data from vehicles 108, for example to allow the control centre system 1 14 to determine the current operational status/position etc. of vehicles 108.

[032] To assist in communications the worksite 100 may be provided with communications infrastructure, such as radio tower 120.

[033] Control centre system 1 14 stores in memory (for example non-transient memory 212) and runs one or more applications allowing operators to operate the system 1 14. Such applications will typically comprise at least an operating system such as Microsoft Windows®, Apple OSX, Unix, or Linux.

[034] As described in detail below, the control centre system 1 14 is configured to perform various process steps. In one embodiment configuration of the control centre system 1 14 to perform the processing described is by the execution of software. The software is stored on memory (e.g. non-transient memory 212 or other computer readable memory accessible by the control centre system 1 14) and comprises instructions (and data). The instructions are read into system memory such (e.g. 208) and executed by the processing unit 204 of the control centre system 1 14 to cause the control centre system 1 14 to implement the various steps described. [035] In alternative embodiments configuration of the control centre system 1 14 may be by hardware circuitry or a combination of hardware circuitry and software.

[036] Control centre system 1 14 may be made up of multiple computer processing systems. Where multiple computer processing systems are used they may be located in the same or different places, and may be directly interconnected or interconnected via a network such as network 220.

[037] As noted, each vehicle 108 is also equipped with a computer processing system 1 16. In Fig. 2 the vehicle system 1 16 is depicted as having the same general architecture and functional components as the control centre system 1 14 described above. Typically, though, vehicle system 1 16 will be a dedicated system tailored specifically for the vehicle in question and the operations that vehicle 108 is intended to perform. Vehicle system 1 16 may be made up of multiple computer processing systems.

[038] As noted above, vehicle 108 is equipped with a plurality of sensors 1 18. Sensors 1 18 are, in essence, input and/or output devices which are operated to sense information regarding the operation of the vehicle 108 and/or characteristics/features of the environment in which the vehicle 108 is operating. By way of non-limiting example, the sensors 1 18 for a vehicle 108 may comprise: a Global Positioning System (GPS) device, an Inertial Measurement Unit (IMU), radar, lidar, range sensors, video cameras, a fuel level sensor, a fuel pump sensor, payload load sensors, tyre pressure sensors, temperature sensors, a speed sensor, a gear sensor, tool position and/or orientation sensors. In addition, vehicles 108 may be equipped with more sophisticated sensor/monitoring systems (each of which may, for example, be an independent or interconnected computer processing system) for monitoring major machine subsystems such as: machine engine; machine transmission; machine suspension; machine tyres; machine steering; machine exhaust; machine electrical and suchlike.

[039] Vehicle system 1 16 further comprises (or is connected to) a plurality of vehicle actuators which control the actual operation of the vehicle. Vehicle actuators are also effectively input/output devices and may comprise, for example, actuators to control steering, acceleration, engine operation, gearing, tool position/movement etc.

[040] Vehicle system 1 16 enables a vehicle 108 to communicate (over a network such as 220 using a communications interface 218) with the control centre system 1 14. This allows the vehicle 108 to communicate messages/data to the control centre 1 12 and to receive messages/data from the control centre 1 12.

[041] As described in detail below, the vehicle system 1 16 is configured to perform various process steps. In one embodiment configuration of the vehicle system 1 16 to perform the processing described is by the execution of software. The software is stored on memory (e.g. non-transient memory 212 or other computer readable memory accessible by the vehicle system 1 16) and comprises instructions (and data). The instructions are read into system memory such (e.g. 208) and executed by the processing unit 204 of the vehicle system 1 16 to cause the of the vehicle system 1 16 to implement the various steps described. [042] In alternative embodiments configuration of the vehicle system 1 16 may be by hardware circuitry or a combination of hardware circuitry and software.

[043] The foregoing description of the control centre system 1 14 and vehicle system 1 16 has been provided by way of non-limiting example only. A wide variety of computer processing systems with different components and/or architectures could be used for either the control centre system 1 14 and/or individual vehicle systems 1 16.

Industrial Applicability

[044] As noted above, certain worksite operations involve vehicles 108 operating near crests 104. One particular example of such an operation is operating dozer vehicles 108 to push material across the surface 102 towards and over a crest 104. [045] As one example this may be performed by slot dozing techniques where a vehicle 108 (e.g. a dozer) operates in a slot 122. Multiple slots 1 10 may be worked in concurrently by multiple vehicles 108 (e.g. vehicles 108a, 108b and 108c). Each slot 122 is approximately parallel to each other slot 122 and runs approximately transverse to the crest 104.

[046] Vehicles 108 are configured to be operable remotely by a human operator from a control centre 1 12 (using a control centre system 1 14). Vehicles 108 are also configured to operate autonomously - i.e. under the autonomous control of vehicle system 1 16 (including, at times, with input from control centre system 1 14).

[047] In one embodiment, at the beginning of a slot dozing operation a human operator remotely controls a dozer vehicle 108 (by operating a control centre system 1 14 to send commands to the vehicle system 1 16 over network 220) to position it at the start of a slot 122 (i.e. the end of the slot 122 that is distal to the crest 104 - see, for example, vehicle 108A). Remotely controlling a vehicle 108 is done with the aid of data sensed by vehicle sensors 1 18 and/or fixed position sensors 1 12 and communicated to the operator to be viewed on a display of a control centre system 1 14.

[048] Once the dozer 108 is correctly positioned at the start of the slot 122 the operator issues a command to the dozer 108 to autonomously perform the required slot dozing operations. This involves the dozer system 1 16 autonomously controlling the vehicle 108 to move towards/approach the crest 104 (gathering material from the surface 102 as it goes), push the gathered material over the edge of the crest 104, stop, reverse back along the slot 122, and repeating until the required amount of material has been moved.

[049] A process such as this is efficient from a human resource point of view as a single operator can be responsible for and effectively control multiple vehicles 108 operating concurrently.

[050] As discussed above, however, it is in some cases desirable for operations occurring near or at a crest 104 to be carefully monitored. When a single operator is responsible for multiple vehicles 108 operating in the general vicinity of a crest 104 their attention may be diverted and they may not be paying attention to vehicle(s) actually accessing the crest 104.

[051] To assist in this the present disclosure provides systems and methods for controlling the number of vehicles 108 that concurrently access a crest 104. More specifically, in the embodiments described below systems and methods are provided for limiting the number of vehicles 108 associated with a given human operator that can simultaneously approach a crest 104.

[052] Data used to control access to a crest 104 in accordance with embodiments will be described. Following this operations performed by a control centre system 1 14 and vehicle system 1 16 in accordance with two embodiments.

Data

[053] This section describes some of the data used by the control centre system 1 14 and/or vehicle systems 1 16 in order to control access to a crest 104.

[054] Crest position data indicating a position of the crest 104 is known - i.e. stored in computer readable memory of the control centre system 1 14 and/or vehicle system 1 16. Where the disclosure is applied to slot dozing operations, a crest position may be stored in respect of each slot (e.g. indicated by 124 in Fig. 1 ). Alternatively, crest position data may comprise a geofence or other series of datapoints indicating the position(s) of crest(s) in the worksite 100. Crest position data may be known based on terrain mapping of the worksite 100 or other techniques.

[055] An addition to the actual crest position 124, a crest area 126 (encompassing the actual crest 104) is defined. In one embodiment the crest area is defined by storing a predetermined distance (indicated as "D" in Fig. 1 ) in computer readable memory - the crest area 126 being the area within the predetermined distance D of the crest position 124. The predetermined distance D is set by the control centre system 1 14 (or an operator using that system) and communicated to vehicles 108 over network 220. The distance is set to be appropriate for the terrain and may differ between slots in different locations. By way of example the predetermined distance may range from 4m to 6m. In one particular embodiment the predetermined distance is approximately 5 meters.

[056] The crest area 126 may be alternatively defined, for example by a geofence.

[057] The control centre system 1 14 also maintains crest access data. The crest access data comprises one or more operator identifiers. Each operator identifier is associated with a human operator who is responsible for one or more vehicles 108. To enable determination of which vehicles 108 a particular operator is responsible for each operator identifier is also associated with one or more vehicle identifiers, a vehicle identifier being associated with/related to a particular vehicle 108. A vehicle identifier may be any appropriate identifier, for example a specially created vehicle identifier, a MAC address of a vehicle communications interface, or another identifier.

[058] Each operator identifier is also associated with a maximum access value and a current access value.

[059] The maximum access value associated with a given operator identifier indicates the maximum number of vehicles associated with that operator that are permitted to simultaneously access a crest 104. For example, if a maximum access value for an operator is set to one (or a value indicating one) then only one vehicle 108 associated with that operator is permitted to access a crest 104 at any given time. If the value indicates two, then at most two vehicles 108 associated with the operator can access a crest 104 at the same time. If the value indicates three, then at most three vehicles 108 associated with the operator can access a crest 104 at the same time.

[060] All operator identifiers may be associated with the same maximum access value. Alternatively, different operators may be assigned different maximum access values. This permits differences in experience and/or current work assignments to be taken into account. For example, the maximum access value of a relatively inexperienced operator may be set to a relatively low value (e.g. one), while the maximum access value of a relatively experienced operator may be set to a relatively high value (e.g. two, three or more). Similarly, operators overseeing higher risk vehicle operations (or vehicle operations on higher-risk terrain) 104 may be assigned relatively low maximum access values, while operators overseeing lower risk vehicle operations (or vehicle operations on lower-risk terrain) may be assigned relatively high maximum access values. [061] The current access value associated with an operator indicates the number of vehicles 108 associated with that operator that currently have been granted permission to access the crest 104. The current access value is updated as vehicles 108 are granted access to the crest 104 and relinquish access to the crest 104 (or crest access otherwise expires). [062] Crest access data is maintained on computer readable memory (e.g. non- transient memory 212) in one or more data structures. Table A below provides one example of a data structure for storing the crest access data described above:

Table A [063] In the example shown by table A : the operator with identifier 1 is associated with two vehicles 108 (vehicle identifiers 1 and 2), the operator can be responsible for only one vehicle 108 accessing a crest 104 at a given time, and there are currently 0 vehicles 108 for which the operator is responsible accessing the crest 104; the operator with identifier 2 is associated with three vehicles 108 (vehicle identifiers 3, 4, and 5), the operator can be responsible for two vehicles 108 accessing a crest 104 at a given time, and there is currently 1 vehicle 108 for which the operator is responsible for accessing the crest 104. [064] Alternative data structures could be used. For example a relational database tables, could be used.

[065] In one embodiment, the control centre system 1 14 also maintains records of the particular vehicles 108 that have been granted access to a crest 104 and the status of that access. These records will be referred to as permit records. Each permit record comprises at least an identifier of a vehicle 108 which has been granted access to a crest 104 (e.g. the vehicle identifier as discussed above).

[066] In the embodiments described below a permit record also comprises or is associated with expiry data which allows an expiry time in respect of the permit record (and, effectively, the access that has been granted) to be determined. The expiry data may define an actual expiry time at which the permit record expires. As an alternative example, the expiry data may comprise a permit issue time and a time interval (the permit expiring once the issue time plus the time interval is reached). Where expiry data is used, any appropriate duration may be used. For example, in one embodiment permit records are set to expire 5 minutes after permission to access a crest 104 is granted.

[067] In alternative embodiments permit records need not be associated with expiry data. In this case a permit record will only expire if explicitly relinquished.

[068] Table B below provides one example of a data structure for storing permit records:

Table B [069] In the example shown by table B expiry data is stored as a time at which the permit record expires. Alternative data structures could be used and additional data could, of course, be stored (for example a permit issue time).

[070] In some embodiments permit records that have expired or that relate to permission that has been relinquished are removed from the data structure (and optionally stored in a historical data structure of expired permit records for review/data analysis purposes). In alternative embodiments expired permits are not removed from the data structure but are maintained. In this case a status data field may be used to flag whether a permit record is current/valid or expired/invalid. Controlling crest access

[071] Generally speaking, the control centre system 1 14 and vehicle system 1 16 operate to ensure that the number of vehicles 108 associated with a given operator and accessing a crest 104 at the same time does not exceed the maximum access value for that operator. [072] At a high level, a vehicle 108 that wishes to approach a crest 104 sends a crest access request to the control centre system 1 14. The control centre system 1 14 receives the crest access request and determines whether or not permission to access the crest 104 should be granted to the vehicle 108 (based on the number of other vehicles 108 for that operator that have currently been granted access). If permission to access the crest is granted, the control centre system 1 14 communicates a permission granted message back to the vehicle system 1 16 and records that an additional vehicle associated with the operator is currently accessing the crest 104. The vehicle system 1 16 receives the permission granted message and approaches the crest. When the vehicle 108 has completed work at the crest 104 (e.g. by pushing the material toward/over the crest 104) it retreats from the crest 104 and communicates a relinquish message to the control centre system 1 14. The control centre system 1 14 receives the relinquish message and records that one less vehicle 108 associated with the operator is currently accessing the crest 104. [073] Once a vehicle has permission that vehicle can move about the crest area. The vehicle can at any time reverse away from the crest 104, even if its permission has expired.

[074] In certain embodiments the permission granted in the permission granted message has a limited life span (i.e. a time to live). If a vehicle 108 requires access to a crest 104 for longer than the life span of the permission that has been granted it can communicate (before expiry of the permission) a renewal request to the control centre system 1 14. The control centre system 1 14 receives the renewal request, extends the lifespan of the access permission granted (if possible), and communicates a permission renewed message to the vehicle system 1 16.

[075] This general process may be implemented in a variety of ways. Two alternative implementations are described below (referred to respectively as a queueless implementation and a queued implementation), but further implementations may be adopted. Controlling crest access: Queueless implementation

[076] This section describes operations performed by the control centre system 1 14 and vehicle system 1 16 to control access to crests 104 in what will be referred to as a queueless implementation.

[077] Operations of the control centre system 1 14 will be described initially, followed by operations of a vehicle 108 (as controlled by the vehicle system 1 14).

Control centre: crest access request

[078] Figure 3 depicts a flowchart 300 depicting processing steps performed by the control centre system 1 14 on receiving a crest access request from a vehicle 108. [079] At 302 the control centre system 1 14 receives a crest access request from a vehicle system 1 16. The crest access request is received over a network such as 220 by a communications interface such as 218.

[080] At 304 the control centre system processing unit 204 is operated to process the crest access request to determine the vehicle identifier of the vehicle 108 that communicated the request. In one embodiment this involves extracting the vehicle identifier from the crest access request. In another embodiment this may involve looking up a vehicle identifier based on other information included in or associated with the crest access request. [081] At 306 the control centre system processing unit 204 is operated to determine the operator identifier of the operator responsible for the vehicle identifier determined at 304. The operator identifier may be included in the crest access request, or may be determined by accessing a look up table (or other data structure) associating operator identifiers with vehicle identifiers. A specific operator may be associated with specific vehicles when the operator logs in/accesses a particular control system (which may be referred to as a remote operator station). For example, a particular remote operator station may be configured to control vehicle A and vehicle B. When the operator logs on to that station the system registers that vehicle A and vehicle B are being controlled by the logged-in operator. [082] At 308 the control centre system processing unit 204 is operated to access the crest access data from the computer readable memory on which it is stored. In particular the control centre system processing unit 204 accesses the crest access data to determine the maximum and current access values in respect of the operator identifier determined at 306. [083] At 310 the control centre system processing unit 204 is operated to determine whether or not permission to access the crest 104 is to be granted to the vehicle 108.

[084] Generally speaking, if the current access value indicates that fewer than the maximum number of vehicles 108 are currently accessing the crest 104 the control centre system processing unit 204 grants access to the crest 104. Conversely, if the number of vehicles 108 currently accessing the crest 104 for the operator is equal to (or greater than) the maximum number of vehicles 108 permitted to concurrently access the crest for that operator the control centre system processing unit 204 does not grant access to the crest 104.

[085] In the present embodiment, the control centre system 1 14 is configured to implement a semaphore approach. The control centre system processing unit 204 stores in memory a crest access semaphore (i.e. a variable) for each operator identifier. The control centre system processing unit 204 initialises the value of the crest access semaphore for a given operator to the maximum access value for that operator. In order to determine whether or not to permit access to the crest at 310, the control centre system processing unit 204 checks the current value of the crest access semaphore associated with the operator identifier determined at 306. If the current value of the crest access semaphore is greater than or equal to 1 , the maximum number of vehicles 108 for the operator has not been reached and access is granted. If the current value of the crest access semaphore is 0, the maximum number of vehicles 108 for the operator has been reached and access is refused.

[086] If, at 310, the control centre system processing unit 204 determines access is to be granted processing proceeds to steps 312, 314 and 316. [087] At 312 the control centre system processing unit 204 is operated to access and update the crest access data stored on the computer readable memory. Specifically, the control centre system processing unit 204 updates the current access value associated with the operator identifier determined at 306 to reflect that an additional vehicle 108 is currently accessing the crest 104. In the present embodiment this is achieved by decrementing the value of the crest access semaphore associated with the operator identifier determined at 306.

[088] At 314 the control centre system processing unit 204 is operated to generate a permit record in respect of the permission that has been granted. In this embodiment the control centre system processing unit 204 writes to computer readable memory a record which comprises the vehicle identifier determined at 304 and expiry data which can be used to calculate an expiry time for the permit record. In order to ensure that the expiry mechanism operates correctly computer system clocks are synchronized. As noted, in other embodiments expiry data may not be recorded. [089] At 316 the control centre system processing unit 204 generates a permission granted message and operates the communications interface 218 to communicate the permission granted message to the vehicle system 1 16 from which the crest access request message was received. In certain embodiments the permission granted message comprises expiry data which allows an expiry time for the access to be determined/calculated. In certain embodiments the permission granted message may also include a token (matching a token received in the crest access request) that allows the vehicle to match the response to the particular request being processed.

[090] Following 316 the process ends.

[091] If, at 310, the control centre system processing unit 204 determines access is not to be granted processing proceeds to step 318.

[092] At 318 the control centre system processing unit 204 generates a permission refused message and operates the communications interface 218 to communicate the permission refused message to the vehicle system 1 16 from which the crest access request message was received. In other embodiments no permission refused message is generated and sent - the vehicle system 1 16 being configured to interpret no response as a refusal.

[093] Following 318 the process ends.

Control centre: relinquish message

[094] Figure 4 depicts a flowchart 400 depicting processing steps performed by the control centre system 1 14 on receiving a relinquish message from a vehicle system 1 16. [095] At 402 the control centre system 1 14 receives a relinquish message from a vehicle system 1 16. The relinquish message is received over a network such as 220 by a communications interface such as 218.

[096] At 404 the control centre system processing unit 204 is operated to process the relinquish message to determine the vehicle identifier of the vehicle 108 that communicated the request.

[097] At 406 the control centre system processing unit is operated to determine the operator identifier for the operator responsible for the vehicle identifier determined at 404. [098] At 408 the control centre system processing unit 204 is operated to access and update the crest access data stored on the computer readable memory. Specifically, the control centre system processing unit 204 updates the current access value associated with the operator identifier determined at 406 to reflect that one less vehicle 108 is currently accessing the crest 104. In the present embodiment this is achieved by incrementing the value of the crest access semaphore associated with the operator identifier determined at 406.

[099] At 410 the control centre system processing unit 204 is operated to update the permit record associated with the vehicle 108 that has communicated the relinquish message 402. Generally speaking, this involves processing the permit record to indicate that the permission represented by the permit record is no longer current/valid. This may be achieved in a variety of ways. In one embodiment the permit record is deleted (optionally historical data in respect of the permit record can be stored elsewhere). In an alternative embodiment a flag is associated with the permit record indicating it is no longer current/valid. In a further alternative embodiment expiry data associated with the permit record is updated to reflect that the permit record has expired (i.e. the expiry data is set to indicate the time the relinquish message was received or a past time).

[100] Following 410 the process ends. Control centre: permit record expiry

[101] Figure 5 depicts a flowchart 500 indicating processing steps performed by the control centre system 1 14 on expiry of a permit record.

[102] As noted, permit records do not expire in all embodiments. In some embodiments permit records exist and remain valid until permission is relinquished by the vehicle 108 associated with the permit record.

[103] At 502 the control centre system 1 14 detects expiry of a permit record. Detection of a permit record expiring may be implemented in various ways. In one embodiment detection is triggered by an interrupt that triggers when an expiry time associated with a permit record is reached. In an alternative embodiment detection may occur on processing a renew request (described further below) results in a determination that the permit record has expired. In a further alternative embodiment detection is triggered by the control centre system 1 14 periodically processing permit records to determine if any permit records are associated with an expiry time that has been reached. Alternative implementations are possible.

[104] At 504 the control centre system processing unit 204 is operated to update the expired permit record to indicate that the permission represented by the permit record is no longer current/valid. This may be achieved in a variety of ways, as described with respect to step 410 of Fig. 4. [105] At 506 the control centre system processing unit 204 determines the operator identifier associated with the vehicle identifier of the permit record detected to have expired at 502.

[106] At 508 the control centre system processing unit 204 is operated to access and update the crest access data stored on the computer readable memory. Specifically, the control centre system processing unit 204 updates the current access value associated with the operator identifier determined at 506 to reflect that one less vehicle 108 is currently accessing the crest 104. In the present embodiment this is achieved by incrementing the value of the crest access semaphore associated with the operator identifier determined at 506.

[107] Following 504 the process ends.

Control centre: renew message [108] Figure 6 depicts a flowchart 600 depicting processing steps performed by the control centre system 1 14 on receiving a renew request from a vehicle system 1 16. In certain embodiments a renew request has the same format as a crest access request message.

[109] At 602 the control centre system 1 14 receives a renew request from a vehicle system 1 16. The renew request is received over a network such as 220 by a communications interface such as 218.

[110] At 604 the control centre system processing unit 204 is operated to process the renew request to determine the vehicle identifier of the vehicle 108 that communicated the renew request. [111] At 606 the control centre system processing unit 204 is operated to access the permit records from computer readable memory.

[112] At 608 the control centre system processing unit 204 is operated to determine whether a current/valid permit record associated with the vehicle identifier determined at 604 exists. [113] This determination can be implemented in a variety of ways depending on how permit records are managed. For example, the control centre system processing unit 204 may be configured to determine that no current/valid permit record exists: if there is no permit record associated with the vehicle identifier; if there is a permit record associated with the vehicle identifier but it has a flag indicating that the record is not current/has expired/is otherwise invalid; if there is a permit record associated with the vehicle identifier but the expiry data in respect of the record indicates the record has expired (on identifying this process 500 of Fig. 5 may be initiated). Conversely, the control centre system processing unit 204 may be configured to determine that a current/valid permit record does exist: if a permit record with the vehicle identifier exists (i.e. in embodiments where expired permit records are deleted the simple existence of a record indicates the validity of that record); if a permit record with the vehicle identifier exists and there is no flag indicating the record is invalid/expired (or there is a flag indicating the record is current); if a permit record with the vehicle identifier exists and the expiry data indicates a time in the future. [114] If, at 608, the control centre system processing unit 204 determines a current/valid permit record associated with the vehicle identifier exists, processing proceeds to steps 610 and 612.

[115] At 610 the control centre system processing unit 204 is operated to update the permit record associated with the vehicle identifier. Specifically, the expiry data associated with the permit record is updated to reflect the new expiry time that has been determined.

[116] At 612 the control centre system processing unit 204 generates a permission renewed message and operates the communications interface 218 to communicate the permission renewed message to the vehicle system 1 16 from which the renew request was received. In the present embodiment the permission renewed message comprises updated expiry data which allows an expiry time for the access to be determined/calculated. In certain embodiments, where permission is renewed the new expiry time is calculated to be the current time (or time at which the renew request was sent or received) plus the "normal" duration for which permission is granted (e.g. an additional 5 minutes). In certain embodiments a permission renewed request has the same format as a permission granted message.

[117] Following 612 the process ends. [118] If, at 608, the control centre system processing unit 204 determines a current/valid permit record associated with the vehicle identifier does not exist, processing proceeds to step 614.

[119] In the present embodiments it unlikely that a valid permit record will not be identified. This is because a vehicle system 1 16 should only request renewal if the vehicle's own data indicates that it has been granted permission to access the crest 104 and that permission has not expired/been relinquished. Despite this it is possible that no valid permit will exist - for example if a delay in communications results in a renew request being sent by a vehicle system 1 16 prior to expiry of the permission, but being received by the control centre system 1 14 after expiry.

[120] At 614 the control centre system processing unit 204 generates a renewal refused message and operates the communications interface 218 to communicate the renewal refused message to the vehicle 108 from which the renew request was received. In other embodiments no renewal refused message is generated and sent - the vehicle 108 configured to interpret no response as a refusal.

[121] Following 614 the process ends.

[122] In some embodiments the request and response messages used in the renewal of a permit are the same messages that are used in an initial permit request. I.e. a "CrestPermissionRequest" message is used when either requesting initial access to a crest or renewed access, and a "CrestPermissionResponse" message is used to respond to a CrestPermissionRequest (whether the request is a request for initial or renewed access).

[123] Not all embodiments involve permitting vehicles to request renewal of permission that has been granted. In implementations which do not provide for renewal to be requested a vehicle 108 must send a new crest access request (e.g. per process 300).

Vehicle: accessing a crest [124] Figure 7 depicts a flowchart 700 of processing steps performed by the vehicle system 1 16 of a vehicle 108 that wishes to approach/access a crest 104.

[125] At 702 the vehicle system 1 16 determines that the vehicle 108 intends to access or is approaching a crest 104. In one embodiment this determination is made by detecting that the vehicle 108 has entered the crest area 126 (i.e. has approached to within the predetermined distance D of the crest 104). Vehicle system 1 16 can detect this, for example, by monitoring its position (using a position sensor such as a GPS) and comparing that to the known position (e.g. 124) of the crest 104 and the predetermined distance D. Distance D is communicated to the vehicle 108 with the slot-dozing work assignment initially sent to the vehicle 108.

[126] At 704 the vehicle system 1 16 generates a crest access request and operates the vehicle's communications interface 218 to communicate the crest access request to the control centre system 1 14. The crest access request comprises a vehicle identifier (for example a unique identifier of the vehicle 108, mac address, or other identifier). The crest access request may also comprise other data, for example a timestamp, a token that allows the vehicle to match a particular response to the request being communicated, and/or other data.

[127] At 706 the vehicle system 1 16 awaits receipt of an access granted message from the control centre system 1 14. [128] If an access granted message is received from the control centre system 1 14, processing proceeds to 708, 710 and 712.

[129] At 708 the access granted message is received via the vehicle's communications interface 218.

[130] At 710 the vehicle system 1 16 processes the access granted message and records in computer readable memory expiry data allowing an expiry time associated with the access that has been granted to be determined. In one embodiment the expiry time (or data allowing an expiry time to be calculated) is included in the access granted message.

[131] At 712 the vehicle system 1 16 controls the vehicle 108 to approach the crest 104 (presuming no other, higher priority, operations are required). [132] Following 712 the process ends.

[133] If, at 706, no access granted message is received from the control centre system 1 14 (or an access refused message is received), processing proceeds to 714 and 716.

[134] At 714 the vehicle system 1 16 stops the vehicle 108 (or, if already stopped) maintains the vehicle in a stopped state) so the vehicle 108 does not approach the crest 104.

[135] At 716 the vehicle system 1 16 delays for a predetermined or calculated delay period. In some embodiments the delay may be quite short, for example a few seconds. [136] Following the delay at 716 the vehicle system 1 16 returns to 704 to communicate a further crest access request to the control system 1 14.

Vehicle: relinquish crest access

[137] Figure 8 depicts a flowchart 800 depicting processing steps performed by the vehicle system 1 16 of a vehicle 108 to relinquish access to a crest. [138] At 802 the vehicle system 1 16 detects that the vehicle 108 no longer requires access to the crest 104. In on embodiment this involves detecting the vehicle 108 retreating from the crest 104. In one embodiment, retreat from a crest 104 is detected by the vehicle system 1 16 detecting the vehicle moving in a reverse direction (or has engaged a reverse gear) while in the crest area 126. [139] At 804 the vehicle system 1 16 generates a relinquish message and operates the vehicle's communications interface 218 to communicate the relinquish message to the control centre system 1 14. The relinquish message comprises a vehicle identifier.

[140] Following 804 the process ends. [141] In certain embodiments the vehicle system 1 16 also generates a relinquish message and communicates this to the control centre system 1 14 when an operator assumes manual control of the vehicle (e.g. remote control).

Vehicle: renew crest access

[142] Figure 9 depicts a flowchart 900 depicting processing steps performed by the vehicle system 1 16 of a vehicle 108 to renew access to a crest.

[143] At 902 the vehicle system 1 16 determines that renewal of the crest access is desired. Detecting that renewal of access is desired can only be achieved where a vehicle 108 has current permission to access the crest 104 (i.e. the vehicle has previously received an access granted message and the permission associated with that message has not expired). By way of example, the vehicle system 1 16 may determine that renewal of the access is desired if it calculates that the vehicle 108 will not have reached the actual crest 104 and be in retreat by the time the permission is due to expire.

[144] At 904 the vehicle system 1 16 generates a renew request and operates the vehicle's communications interface 218 to communicate the renew request to the control centre system 1 14. The renew request comprises a vehicle identifier. In certain embodiments a renew request has the same format as a crest access request.

[145] At 906 the vehicle system 1 16 awaits receipt of a renew granted message from the control centre system 1 14. [146] If a renew granted message is received from the control centre system 1 14, processing proceeds to 908, 910, and 912.

[147] At 908 the renew granted message is received via the vehicle's communications interface 218. In certain embodiments a renew granted message has the same format as a permission granted message (though, of course, has an updated expiry value).

[148] At 910 the vehicle system 1 16 processes the renew granted message and records a new expiry time associated with the permission that has been renewed. In one embodiment the expiry time (or data allowing an expiry time to be calculated) is included in the renew granted message.

[149] At 912 the vehicle system 1 16 permits or controls the vehicle to continue operations in the crest area 126 (e.g. to continue approaching the crest 104).

[150] Following 912 the process ends.

[151] If, at 906, no renew granted message is received from the control centre system 1 14 (or a renew refused message is received), processing proceeds to 914. As noted above, in the present embodiment it will be rare for renewal not to be granted.

[152] At 914 the vehicle system 1 16 operates the vehicle in accordance with the original crest access request that was granted. If a renew request has been communicated the original permission will typically have expired or be just about to expire, in which case operating the vehicle 108 in accordance with the original permission that was granted will involve operating the vehicle 108 to cease approaching the crest 104 or to retreat from the crest 104.

[153] Following 912 the process ends.

Controlling crest access: Queued implementation [154] This section describes an alternative implementation in which the control centre system 1 14 maintains a queue of vehicle identifiers in respect of vehicles 108 that have requested permission to access a crest but for which access has not been granted. [155] Much of the implementation described in this section is similar to the queueless implementation described above. Processing steps that are the same or substantially the same as those described above are indicated by the reference numerals of their counterpart steps in the queueless implementation and will not be described again in this section. [156] In the queued implementation the control centre system 1 14 further maintains (i.e. stores in computer readable memory) a queue in respect of each operator identifier. Each queue is a first-in-first-out queue and, as described below, is used to record vehicles 108 that have requested access to the crest at a time when access could not be granted. Control centre: crest access request

[157] Figure 3 depicts a flowchart 300 of processing steps performed by the control centre system 1 14 on receiving a crest access request from a vehicle 108.

[158] Steps 302, 304, and 306 are the same as or similar to those steps as described above. Generally speaking these steps involve receiving a crest access request (302), determining a vehicle identifier (304) and determining an operator identifier (306).

[159] At 1002 the control centre system processing unit 204 is operated to access and update the crest access data stored on the computer readable memory. Specifically, the control centre system processing unit 204 updates the current access value associated with the operator identifier determined at 306 to reflect that an additional vehicle 108 has requested access to the crest 104. In the present embodiment this is achieved by decrementing the value of the crest access semaphore associated with the operator identifier determined at 306. [160] At 1004 the control centre system processing unit 204 is operated to determine whether or not crest access is to be granted to the vehicle 108. In the present embodiment, crest access semaphore values are initialised to the maximum access value for the associated operator. If the current value of the crest access semaphore is less than zero (following the value being decremented at 1002) permission to access the crest 104 is refused. If the current value of the crest access semaphore is greater than or equal to zero permission to access the crest 104 is granted.

[161] If, at 1004, the control centre system processing unit 204 determines permission to access the crest 104 is to be granted processing proceeds to steps 314 and 316. These steps are as described above, the control centre system 1 14 generating a permit record (at 314) and generating and communicating a permission granted message (at 316).

[162] Following 316 the process ends.

[163] If, at 1004, the control centre system processing unit 204 determines access is not to be granted processing proceeds to step 318 and 1006.

[164] At 318 the control centre system 1 14 generates and communicates a permission refused message to the vehicle system 1 16.

[165] At 1006, the control centre processing unit 204 adds the vehicle identifier determined at 304 to the end of the queue associated with the operator identifier determined at 306.

[166] Following 1006 the process ends.

Control centre: relinquish message

[167] Figure 1 1 depicts a flowchart 1 100 of processing steps performed by the control centre system 1 14 on receiving a relinquish message from a vehicle 108. [168] Steps 402, 404, 406, 408, and 410 are the same as or similar to those steps as described above. In the present embodiment, updating the crest access data in respect of the operator at 408 comprises incrementing the value of the crest access semaphore associated with that operator. [169] At 1 102 the control centre system processing unit 204 determines whether or not there are any queued vehicles 108 for the operator and, if so, whether a queued vehicle can now be given permission to access the crest 104.

[170] In the present embodiment this is achieved by checking the value of the current access semaphore for the operator determined at 406. If the current access semaphore (after being incremented at 408) is zero this indicates there is a queued vehicle 108 and crest access can be given to that vehicle 108. If the current access semaphore is negative this indicates that there are queued vehicles 108 but that access to the crest cannot currently be given (i.e. the maximum number of vehicles for the operator are currently accessing the crest). If the current access semaphore is greater than zero this indicates that there are no queued vehicles (and that crest access is available).

[171] If, at 1 102, the control centre system processing unit 204 determines that there are no queued vehicles that can be given permission to access the crest (either due to there being no queued vehicles 108 or there being queued vehicles 108 but permission cannot be granted) the process ends.

[172] If, at 1 102, the control centre system processing unit 204 determines that there is a queued vehicle that can now be given permission to access the crest the process proceeds to 1 104, 314, and 316.

[173] At 1 104 the control centre system processing unit 204 accesses the queue for the operator determined at 406. The vehicle identifier of the first queue entry is read and the first entry removed from the queue. [174] At 314 the control centre system 1 14 generates a permit record in respect of the crest access that has been granted.

[175] At 316 the control centre system 1 14 generates and communicates a permission granted message to the vehicle identified by the queue entry removed at 1 104.

[176] Following 316 the process ends. Control centre: permit record expiry

[177] Figure 12 depicts a flowchart 1200 of processing steps performed by the control centre system 1 14 on expiry of a permit record. [178] Steps 502, 504, 506, and 508 are the same as or similar to those steps as described above. These steps generally involve detecting expiry of a permit record, updating the permit record, determining the operator associated with the vehicle to which the expired permit record relates, and updating the crest access data for that operator (in this case by incrementing the operator's crest access semaphore). [179] After incrementing the operator's crest access semaphore at 508, steps the same or similar to steps 1 102, 1 104, 312, and 316 of Fig. 1 1 (with respect to receiving a relinquish message) are performed. In short, the control centre system 1 14 determines whether or not there is a queued vehicle for the operator which can now be granted permission to access the crest 104 and, if so, permission to access the crest 104 is granted and data updated accordingly.

Control centre: renew message

[180] The processing performed by the control centre system 1 14 on receiving a renew request may be the same as in the queueless example described above with respect to Fig. 6. [181] In alternative embodiments the control centre system 1 14 may be configured to only grant a renew request if the queue of vehicles for the operator in question is empty. In this embodiment, if a renew request is received but the queue for the relevant operator is not empty the renew request is refused. Vehicle: accessing a crest

[182] Figure 13 depicts a flowchart 1300 of processing steps performed by the vehicle system 1 16 of a vehicle 108 that wishes to approach/access a crest 104.

[183] Process 1300 includes steps 702, 704, 706, 708, 710, 712, and 714 which are the same as or similar to those steps as described above with respect to Fig. 7. [184] If, at 706, an access granted message is not received from the control centre system 1 14 (or an access refused message is received), the process proceeds to 714.

[185] At 714 the vehicle system 1 16 stops the vehicle 108 (or maintains the vehicle in a stopped state) so the vehicle 108 does not approach the crest 104.

[186] Following 714 the process returns to 706 to await receipt of an access granted message from the control system 1 14. This is in contrast to the queueless implementation described above where on being refused access the vehicle system 1 16 delays and re-requests crest access. This reflects the fact that in this particular embodiment the vehicle's crest access request is queued and the control centre 1 14 will notify the vehicle 108 when it can access the crest 104. Vehicle: relinquish crest access

[187] The processing performed by a vehicle system 1 16 to relinquish access is the same as described above with respect to Fig. 8.

Vehicle: renew crest access [188] The processing performed by a vehicle system 1 16 on determining a desire to renew access to a crest 104 is the same as described above with respect to Fig. 9.

Embodiments

[189] Alternative embodiments and implementations to those described above are possible.

[190] For example, the manner in which the crest access data (maximum and current crest access values) is recorded and the manner in which decisions are made in respect of that data may vary. In the embodiments described above the current access value is initialised to the maximum access value, on granting access the current value is decremented, and on access expiring/being relinquished the current value is incremented. In an alternative implementation the current access value could be initialised to zero, and incremented on access being granted (and decremented on access being relinquished/expiring). In this case determination of whether access can be granted (e.g. at 310) involves whether the current access value is less than the maximum access value.

[191] In the embodiments described above permit records are associated with expiry data (allowing an expiry of the permit/access to be determined or calculated). In alternative embodiments no expiry data may be use: in this case permit records do not expire and are only invalidated if relinquished by a vehicle. [192] Various flowcharts have been provided above to describe operations of the control centre system 1 14 and vehicle systems 1 16. While these flowcharts illustrate various processing steps in a specific order, it will be appreciated that not all embodiments require all processing stages to be performed. Furthermore, the order in which steps are performed may in some cases be varied and/or it may be possible to perform certain steps in parallel. Still further, while the flowcharts have been presented to illustrate the processing at a certain functional level, it may be possible for one or more steps to be combined into a single processing step and/or for a single processing step to be separated into multiple distinct steps. [193] While the example of slot dozing near a crest was provided, the features disclosed herein may be applied to other operations which involve dozers or other vehicles (operating autonomously or semi-autonomously) operating near a crest area.

[194] The following clauses describe certain embodiments of the present disclosure by way of non-limiting example:

[195] Clause 1 . A computer processing system for controlling autonomous vehicle access to a crest, the computer processing system comprising: a computer processing unit; computer readable memory in communication with the computer processing unit, the computer readable memory storing crest access data comprising one or more operator identifiers and defining, for the or each operator identifier, a maximum access number and a current access number, the maximum access number defining a maximum number of vehicles associated with the operator identifier permitted to concurrently access the crest and the current access number defining a number of vehicles associated with the operator identifier that have currently been granted permission to access the crest; a communications interface in communication with the computer processing unit; and instructions executable by the computer processing unit to cause the computer processing system to: receive, via the communications interface, a crest access request from a vehicle; determine a relevant operator identifier associated with the vehicle; read the crest access data to determine whether the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier; and in response to determining that the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier: operate the communications interface to communicate a permission granted message to the vehicle; and update the crest access data to record that an additional vehicle associated with the relevant operator identifier is currently accessing the crest.

[196] Clause 2. The computer processing system according to clause 1 , wherein in response to determining that the current access number associated with the relevant operator identifier is equal to or greater than the maximum access number associated with the relevant operator identifier, the instructions cause the computer processing unit to: operate the communications interface to communicate a permission refused message to the vehicle.

[197] Clause 3. The computer processing system according to clause 1 or clause 2, wherein the instructions cause the computer processing unit to: receive, via the communications interface, a relinquish message from a vehicle; determine a particular operator identifier associated with the vehicle from which the relinquish message was received; update the crest access data to record that one less vehicle associated with the particular operator identifier is currently accessing the crest. [198] Clause 4. The computer processing system according to according to any one of clauses 1 to 3, wherein the crest access request comprises a vehicle identifier, and in response to determining that the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier the instructions cause the computer processing unit to: generate and store a permit record, the permit record being associated with the vehicle identifier included in the crest access request and being associated with an expiry time at which the permit record is no longer valid.

[199] Clause 5. The computer processing system according to according to clause 4, wherein the instructions cause the computer processing unit to: receive, via the communications interface, a relinquish message from a vehicle, the relinquish message comprising a vehicle identifier; determine a particular operator identifier associated with the vehicle identifier included in the relinquish message; update the crest access data to record that one less vehicle associated with the particular operator identifier is currently accessing the crest; and update the permit record associated with the vehicle identifier included in the relinquish message to indicate that the permit record is not valid.

[200] Clause 6. The computer processing system according to clause 4 or clause 5, wherein the instructions cause the computer processing unit to: receive, via the communications interface, a renew request from a vehicle, the renew request including an identifier of the vehicle; determine whether a valid permit record associated with the vehicle identifier included in the renew request exists; and in response to determining that a valid permit record associated with the vehicle identifier included in the renew request exists, updating the expiry time at which the permit record is no longer valid.

[201] Clause 7. The computer processing system according to according to any one of clauses 4 to 6, wherein the instructions cause the computer processing unit to: determine that a particular permit record is no longer valid; determine the operator identifier that is associated with the vehicle identifier that is associated with the particular permit record; and update the crest access data to record that one less vehicle associated with the operator identifier is currently accessing the crest.

[202] Clause 8. The computer processing system according to any one of clauses 1 to 7, wherein the crest access data comprises at least two operator identifiers and wherein a maximum access number associated with a first operator identifier is different to a maximum access number associated with a second operator identifier.

[203] Clause 9. The computer processing system according to any one of clauses 1 to 8, wherein: for the or each operator identifier the crest access data comprises a semaphore, a threshold value of the semaphore defining the maximum access number and a current value of the semaphore allowing calculation of the current number, and updating the current access number associated with the relevant operator identifier to record that an additional vehicle is currently accessing the crest comprises adjusting the current value of the semaphore. [204] Clause 10. The computer processing system according to any one of clauses 1 to 9, wherein: the crest access request received from the vehicle comprises a vehicle identifier; and in response to determining that the current access number associated with the relevant operator identifier is equal to or greater than the maximum access number associated with the relevant operator identifier, the instructions cause the computer processing unit to add the vehicle identifier to a queue of vehicle identifiers.

[205] Clause 1 1 . The computer processing system according to according to clause 10, wherein the instructions cause the computer processing unit to: receive, via the communications interface, a relinquish message from a vehicle, the relinquish message comprising a vehicle identifier; determine a particular operator identifier associated with the vehicle identifier included in the relinquish message; update the crest access data to record that one less vehicle associated with the particular operator identifier is currently accessing the crest; and determine if there is at least one vehicle identifier in the queue of vehicle identifiers; and in response to determining there is at least one vehicle identifier in the queue of vehicle identifiers: operate the communications interface to communicate a permission granted message to the vehicle indicated by the first vehicle identifier in the queue of vehicle identifiers; and remove the first vehicle identifier in the queue of vehicle identifiers from the queue of vehicle identifiers.

[206] Clause 12. The computer processing system according to according to claim 10, wherein the instructions cause the computer processing unit to: determine that a permission granted to a particular vehicle to access a crest is no longer valid; in response to determining that the permission granted to the particular vehicle is no longer valid: determine if there is at least one vehicle identifier in the queue of vehicle identifiers; and in response to determining there is at least one vehicle identifier in the queue of vehicle identifiers: operate the communications interface to communicate a permission granted message to the vehicle indicated by the first vehicle identifier in the queue of vehicle identifiers; and remove the first vehicle identifier in the queue of vehicle identifiers from the queue of vehicle identifiers.

[207] Clause 13. A vehicle configured to operate autonomously in a crest area, the vehicle configured to: detect an approach towards a crest located in the crest area; in response to detecting the approach towards the crest, operate a communications interface to communicate a crest access request to a control system; in response to not receiving a permission granted message from the control system, not approaching the crest; and in response to receiving a permission granted message from the control system: approach the crest; and record, in computer readable memory, a permission expiry time associated with the permission granted by the permission granted message.

[208] Clause 14. The vehicle according to clause 13, wherein the vehicle is further configured to: determine, before expiry of the permission expiry time, that access to the crest will be required after the permission expiry time; in response to determining that access to the crest will be required after the permission expiry time, operating the communications interface to communicate a renew request to the control system.

[209] Clause 15. The vehicle according to clause 13 or clause 14, wherein the vehicle is further configured to: detect a retreat from the crest; and in response to detecting the retreat from the crest, operate the communications interface to communicate a relinquish message to the control system.

[210] Clause 16. The vehicle according to any one of clauses 13 to 15, wherein detecting an approach towards the crest of the crest area comprises detecting that the vehicle has approached to within a predefined distance of the crest.

[211] Clause 17. The vehicle according to clause 16, wherein detecting that the vehicle has approached to within the predefined distance of the crest comprises: accessing data defining a crest position; accessing data defining a current vehicle position; and detecting movement of the vehicle from a position where a distance between the current vehicle position and the crest position is greater than the predefined distance to a position where a distance between the current vehicle position and the crest position is less than or equal to the predefined distance.

[212] Clause 18. The vehicle according to clause 15, wherein detecting the retreat from the crest comprises detecting the vehicle reversing.

[213] Clause 19. The vehicle according to any one of clauses 13 to 18, wherein in response to not receiving a permission granted message from the control system the vehicle is further configured to: wait for a predetermined wait period; and on expiry of the predetermined wait period, operate the communications interface to communicate a further crest access request to the control system. [214] Clause 20. A non-transitory computer-readable medium comprising instructions which, when implemented by a computer processing system, cause the computer processing system to: receive, via a communications interface, a crest access request from a vehicle; determine a relevant operator identifier associated with the vehicle; read crest access data to determine whether a current access number associated with the relevant operator identifier is less than a maximum access number associated with the relevant operator identifier; and in response to determining that the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier: operate the communications interface to communicate a permission granted message to the vehicle; and update the crest access data to record that an additional vehicle associated with the relevant operator identifier is currently accessing the crest.

[215] Clause 21 . A non-transitory computer-readable medium comprising instructions which, when implemented by a computer processing system, cause the computer processing system to: detect an approach of a vehicle towards a crest located in a crest area; in response to detecting the approach towards the crest, operate a communications interface to communicate a crest access request to a control system; in response to not receiving a permission granted message from the control system, preventing the vehicle from approaching the crest; and in response to receiving a permission granted message from the control system: allowing the vehicle to approach the crest; and recording, in computer readable memory, a permission expiry time associated with the permission granted by the permission granted message.

[216] It will be understood that embodiments extend to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects.

Claims

1 . A computer processing system (1 14) for controlling autonomous vehicle access to a crest (104), the computer processing system (1 14) comprising: a computer processing unit (204); computer readable memory (210, 212) in communication with the computer processing unit (204), the computer readable memory (210, 212) storing crest access data comprising one or more operator identifiers and defining, for the or each operator identifier, a maximum access number and a current access number, the maximum access number defining a maximum number of vehicles (108) associated with the operator identifier permitted to concurrently access the crest (104) and the current access number defining a number of vehicles (108) associated with the operator identifier that have currently been granted permission to access the crest (104); a communications interface (218) in communication with the computer processing unit (204); and instructions executable by the computer processing unit (204) to cause the computer processing system (1 14) to: receive, via the communications interface (218), a crest access request from a vehicle (108); determine a relevant operator identifier associated with the vehicle (108); read the crest access data to determine whether the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier; and in response to determining that the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier: operate the communications interface (218) to communicate a permission granted message to the vehicle (108); and update the crest access data to record that an additional vehicle (108) associated with the relevant operator identifier is currently accessing the crest (104).

2. The computer processing system (1 14) according to claim 1 , wherein the instructions cause the computer processing unit (204) to: receive, via the communications interface (218), a relinquish message from a vehicle (108); determine a particular operator identifier associated with the vehicle (108) from which the relinquish message was received; update the crest access data to record that one less vehicle (108) associated with the particular operator identifier is currently accessing the crest (104).

3. The computer processing system (1 14) according to according to claim 1 , wherein the crest access request comprises a vehicle identifier, and in response to determining that the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier the instructions cause the computer processing unit (204) to: generate and store a permit record, the permit record being associated with the vehicle identifier included in the crest access request and being associated with an expiry time at which the permit record is no longer valid.

4. The computer processing system (1 14) according to according to claim 3, wherein the instructions cause the computer processing unit (204) to: receive, via the communications interface (218), a relinquish message from a vehicle (108), the relinquish message comprising a vehicle identifier; determine a particular operator identifier associated with the vehicle identifier included in the relinquish message; update the crest access data to record that one less vehicle (108) associated with the particular operator identifier is currently accessing the crest (104); and update the permit record associated with the vehicle identifier included relinquish message to indicate that the permit record is not valid.

5. The computer processing system (1 14) according to claim 1 , wherein the crest access data comprises at least two operator identifiers and wherein a maximum access number associated with a first operator identifier is different to a maximum access number associated with a second operator identifier.

6. The computer processing system (1 14) according to claim 1 , wherein: the crest access request received from the vehicle (108) comprises a vehicle identifier; and in response to determining that the current access number associated with the relevant operator identifier is equal to or greater than the maximum access number associated with the relevant operator identifier, the instructions cause the computer processing unit (204) to add the vehicle identifier to a queue of vehicle identifiers.

7. A vehicle (108) configured to operate autonomously in a crest area (126), the vehicle (108) configured to: detect an approach towards a crest (104) located in the crest area (126); in response to detecting the approach towards the crest (104), operate a communications interface (218) to communicate a crest access request to a control system (1 14); in response to not receiving a permission granted message from the control system (1 14), not approaching the crest (104); and in response to receiving a permission granted message from the control system

(1 14): approach the crest (104); and record, in computer readable memory (210, 212), a permission expiry time associated with the permission granted by the permission granted message.

8. The vehicle (108) according to claim 7, wherein the vehicle (108) is further configured to: determine, before expiry of the permission expiry time, that access to the crest (104) will be required after the permission expiry time; in response to determining that access to the crest will be required after the permission expiry time, operating the communications interface (218) to communicate a renew request to the control system (1 14).

9. The vehicle (1 08) according to claim 7, wherein the vehicle (108) is further configured to: detect a retreat from the crest (104); and in response to detecting the retreat from the crest (104), operate the communications interface (218) to communicate a relinquish message to the control system (1 14).

10. A non-transitory computer-readable medium (212) comprising instructions which, when implemented by a computer processing system (1 14), cause the computer processing system (1 14) to: receive, via a communications interface (218), a crest access request from a vehicle (108); determine a relevant operator identifier associated with the vehicle (108); read crest access data to determine whether a current access number associated with the relevant operator identifier is less than a maximum access number associated with the relevant operator identifier; and in response to determining that the current access number associated with the relevant operator identifier is less than the maximum access number associated with the relevant operator identifier: operate the communications interface (218) to communicate a permission granted message to the vehicle (108); and update the crest access data to record that an additional vehicle (108) associated with the relevant operator identifier is currently accessing the crest (104).