High definition map updates using assets generated by an autonomous vehicle fleet

The disclosed technology provides solutions for updating high definition maps based on low resolution map assets. In some aspects, a process of receiving a change detection relating to a change in the real world is provided. The process can include steps for receiving autonomous vehicle drive data based on the change in the real world, generating low resolution tile data based on the autonomous vehicle drive data based on the change in the real world, generating updated semantic data based on the low resolution tile data generated, and providing the updated semantic data to an autonomous vehicle to update a proximate area of the change in the real world of a base map of the autonomous vehicle. Systems and machine-readable media are also provided.

BACKGROUND

1. Technical Field

The subject technology provides solutions for autonomous vehicles, and in particular, for updating high definition maps based on low resolution map assets.

Autonomous vehicles (AVs) are vehicles having computers and control systems that perform driving and navigation tasks that are conventionally performed by a human driver. As AV technologies continue to advance, ride-sharing services will increasingly utilize AVs to improve service efficiency and safety. However, AVs will be required to perform many of the functions that are conventionally performed by human drivers, such as avoiding dangerous or difficult routes, and performing other navigation and routing tasks necessary to provide a safe and efficient transportation. Such tasks may require the collection and processing of large quantities of data using various sensor types, including but not limited to cameras, radars, and/or Light Detection and Ranging (LiDAR) sensors disposed on the AV.

DETAILED DESCRIPTION

As described herein, one aspect of the present technology is the updating of high definition maps based on low resolution map assets. The present disclosure contemplates that in some instances, the low resolution map assets may provide updates to an autonomous vehicle regarding an avoidance area. The present disclosure contemplates utilizing high resolution tile tracking, low resolution tile tracking, and/or semantic label tracking.

In conventional autonomous vehicle (AV) deployments, there are two types of map updates: 1) Base Lidar Map Updates; and 2) Semantic Feature Updates. Both types of map updates require data collection using “mapping cars” that drive around to collect high resolution lidar and camera data, which is then processed to generate assets that are ready for labelling. This process typically takes approximately days to potentially weeks from map data collection through mapping cars. In such cases, map assets are not being efficiently utilized and the process also adds extra, unnecessary latency to the map update time period. For example, this process adds latency to the map update process since the process is dependent on sending out mapping cars to map a given area to make any kind of small or large map updates.

Moreover, mapping operations are also limited by their ability of utilizing a mapping vehicle, which includes a special set of sensors to generate the high definition (HD) map (e.g., lidar maps) for the autonomous vehicle. As map changes are detected, avoidance area designations are established so that autonomous vehicles avoid these areas. This reduces routability, thereby increasing trip time and reducing the ability to launch a successful ride share service.

Aspects of the disclosed technology address the foregoing limitations of conventional map updates by providing solutions including providing updated map assets and 2D semantic features as the real world changes. In some aspects, the disclosed technology can reduce the time to respond to a change in the real world (e.g., via detection and signal). In other aspects, the disclosed technology can reduce the time to update semantic labels from a confirmed change to a semantic map. The disclosed technology can further improve the rate at which avoidance areas are lifted, thereby improving trip time, routing, and exposure to more mapped area for the autonomous vehicle. Moreover, the disclosed technology can include data collection efficiency including the time to update the lidar base map, which releases pressure on redrive pipelines/mapping vehicles. Furthermore, the disclosed technology can reduce the cost of maintaining the map, reduced by the cost of mapping vehicle operators and map processing pipelines.

As discussed in further detail below, the disclosed technology further contemplates a mapping operations workflow that can include: 1) reduced time for map data collection and semantic label updates; and 2) fully leverage data collected by autonomous vehicles for map updates and effective scaling of map data collection operations.

FIG.1illustrates an example system environment100that can be used to facilitate AV dispatch and operations, according to some aspects of the disclosed technology. Autonomous vehicle102can navigate about roadways without a human driver based upon sensor signals output by sensor systems104,106. . .108of autonomous vehicle102. Autonomous vehicle102includes a plurality of sensor systems104-108(a first sensor system104through an Nth sensor system108). Sensor systems104-108are of different types and are arranged about the autonomous vehicle102. For example, first sensor system104may be a camera sensor system and the Nth sensor system108may be a Light Detection and Ranging (LIDAR) sensor system. Other exemplary sensor systems include radio detection and ranging (RADAR) sensor systems, Electromagnetic Detection and Ranging (EmDAR) sensor systems, Sound Navigation and Ranging (SONAR) sensor systems, Sound Detection and Ranging (SODAR) sensor systems, Global Navigation Satellite System (GNSS) receiver systems such as Global Positioning System (GPS) receiver systems, accelerometers, gyroscopes, inertial measurement units (IMU), infrared sensor systems, laser rangefinder systems, ultrasonic sensor systems, infrasonic sensor systems, microphones, or a combination thereof. While two sensors104,106are illustrated coupled to the autonomous vehicle102, it is understood that more or fewer sensors may be coupled to the autonomous vehicle102.

Autonomous vehicle102further includes several mechanical systems that are used to effectuate appropriate motion of the autonomous vehicle102. For instance, the mechanical systems can include but are not limited to, vehicle propulsion system130, braking system132, and steering system134. Vehicle propulsion system130may include an electric motor, an internal combustion engine, or both. The braking system132can include an engine brake, brake pads, actuators, and/or any other suitable componentry that is configured to assist in decelerating autonomous vehicle102. In some cases, braking system132may charge a battery of the vehicle through regenerative braking. Steering system134includes suitable componentry that is configured to control the direction of movement of the autonomous vehicle102during navigation. Autonomous vehicle102further includes a safety system136that can include various lights and signal indicators, parking brake, airbags, etc. Autonomous vehicle102further includes a cabin system138that can include cabin temperature control systems, in-cabin entertainment systems, etc.

Autonomous vehicle102additionally comprises an internal computing system110that is in communication with sensor systems104-108and systems130,132,134,136, and138. Internal computing system110includes at least one processor and at least one memory having computer-executable instructions that are executed by the processor. The computer-executable instructions can make up one or more services responsible for controlling autonomous vehicle102, communicating with remote computing system150, receiving inputs from passengers or human co-pilots, logging metrics regarding data collected by sensor systems180and human co-pilots, etc.

Internal computing system110can include a control service112that is configured to control operation of vehicle propulsion system130, braking system132, steering system134, safety system136, and cabin system138. Control service112receives sensor signals from sensor systems104-108as well as communicates with other services of internal computing system110to effectuate operation of autonomous vehicle102. In some embodiments, control service112may carry out operations in concert one or more other systems of autonomous vehicle102. Internal computing system110can also include constraint service114to facilitate safe propulsion of autonomous vehicle102. Constraint service114includes instructions for activating a constraint based on a rule-based restriction upon operation of autonomous vehicle102. For example, the constraint may be a restriction upon navigation that is activated in accordance with protocols configured to avoid occupying the same space as other objects, abide by traffic laws, circumvent avoidance areas, etc. In some embodiments, the constraint service114can be part of control service112.

The internal computing system110can also include communication service116. The communication service116can include both software and hardware elements for transmitting and receiving signals from/to the remote computing system150. Communication service116is configured to transmit information wirelessly over a network, for example, through an antenna array that provides personal cellular (long-term evolution (LTE), 3G, 4G, 5G, etc.) communication.

Internal computing system110can also include latency service118. Latency service118can utilize timestamps on communications to and from remote computing system150to determine if a communication has been received from the remote computing system150in time to be useful. For example, when a service of the internal computing system110requests feedback from remote computing system150on a time-sensitive process, the latency service118can determine if a response was timely received from remote computing system150as information can quickly become too stale to be actionable. When the latency service118determines that a response has not been received within a threshold, latency service118can enable other systems of autonomous vehicle102or a passenger to make necessary decisions or to provide the needed feedback.

Internal computing system110can also include a user interface service120that can communicate with cabin system138in order to provide information or receive information to a human co-pilot or human passenger. In some embodiments, a human co-pilot or human passenger may be required to evaluate and override a constraint from constraint service114, or the human co-pilot or human passenger may wish to provide an instruction to the autonomous vehicle102regarding destinations, requested routes, or other requested operations.

As described above, the remote computing system150is configured to send/receive a signal from the autonomous vehicle140regarding reporting data for training and evaluating machine learning algorithms, requesting assistance from remote computing system150or a human operator via the remote computing system150, software service updates, rideshare pickup and drop off instructions, etc.

Remote computing system150includes an analysis service152that is configured to receive data from autonomous vehicle102and analyze the data to train or evaluate machine learning algorithms for operating the autonomous vehicle102. The analysis service152can also perform analysis pertaining to data associated with one or more errors or constraints reported by autonomous vehicle102. Remote computing system150can also include a user interface service154configured to present metrics, video, pictures, sounds reported from the autonomous vehicle102to an operator of remote computing system150. User interface service154can further receive input instructions from an operator that can be sent to the autonomous vehicle102.

Remote computing system150can also include an instruction service156for sending instructions regarding the operation of the autonomous vehicle102. For example, in response to an output of the analysis service152or user interface service154, instructions service156can prepare instructions to one or more services of the autonomous vehicle102or a co-pilot or passenger of the autonomous vehicle102. Remote computing system150can also include rideshare service158and package service162configured to interact with ridesharing applications170operating on (potential) passenger computing devices. The rideshare service158and/or delivery service172can receive requests to be picked up or dropped off from passenger ridesharing app170and can dispatch autonomous vehicle102for the trip. The rideshare service158can also act as an intermediary between the ridesharing app170and the autonomous vehicle wherein a passenger might provide instructions to the autonomous vehicle to102go around an obstacle, change routes, honk the horn, etc. Remote computing system150can, in some cases, include at least one computing system150as illustrated in or discussed with respect toFIG.4, or may include at least a subset of the components illustrated inFIG.4or discussed with respect to computing system150.

FIG.2illustrates steps of an example process200for updating high definition maps based on low resolution map assets, according to some aspects of the disclosed technology. Process200begins with step202, in which a remote computing system (e.g., remote computing system150ofFIG.1), offline service center, cloud-based computing system, or any other system suitable for the intended purpose and understood by a person of ordinary skill in the art, receives a change detection. For example, an autonomous vehicle may detect a change in a map during a drive. In some embodiments, after the drive, change detectors can be executed on autonomous vehicle data that can also be stored in a remote computing system (e.g., a change detection platform). For example, the change detector process can be executed “offline” and may take place after the drive actually occurs. The change detector process can further include a reviewer who checks when a change detector flags a change and validates that the detected change, in fact, needs to be updated.

A change detection platform can be configured to manage change detection signals by modulating between high-quality and low-quality signals on a per-region basis. In some embodiments, the change detection platform can manage change detection signals as a function of signal source. For example, the change detection platform can predict accuracy and/or relevance of data received from various map change data sources, including but not limited to: human operators, online change detectors, offline change detectors, and/or third-party data streams, etc. The change detection system can further calculate highly granular map change data for a given geographic region (or an entire map, for example, by predicting accuracy, precision, and/or recall statistics for different map feature types.

The change that is detected can include removed/replaced traffic signs, construction barriers, lane marking changes, or any other changes between two versions of maps (e.g., between the real world and the map on the autonomous vehicle). The remote computing system may also receive a signal aggregation message from autonomous vehicles of a fleet, users, or electronic devices relating to a change detected in a map for the autonomous vehicle. In some embodiments, notes or signals can be received from autonomous vehicle operators of a supervised fleet and indicate a change in a map feature to detect changes and place avoidance areas around the detected change. In another embodiment, change detection algorithms can be utilized by the autonomous vehicle or change detection platform that are feature specific on drive data from an autonomous vehicle fleet. These change detection algorithms can be based on camera images and lidar data.

In some implementations, if the remote computing system receives a change detection at step202, process200may advance to step204, in which the remote computing system designates an avoidance area around the location of the change that is detected. By designating an avoidance area, autonomous vehicles of the fleet can update routes around the designated area to efficiently reach their intended final destination without encountering the location of a map feature change (e.g., the real world change).

Process200can also include a step of determining whether a recent autonomous vehicle drive proximate to the detected real world change is available at step206. If available, process200can proceed to step208, which includes generating low resolution tile data from the available autonomous vehicle drive data. One example includes the remoting computing system receiving and analyzing autonomous vehicle data received from autonomous vehicles of the fleet to generate the low resolution tile data based on the autonomous vehicle data at step208of process200. Alternatively, an autonomous vehicle can generate the low resolution tile data based on the autonomous vehicle data, the autonomous vehicle data either being from its own autonomous vehicle data or autonomous vehicle data from another autonomous vehicle. The autonomous vehicle drive data can include camera imagery data from the autonomous vehicle. Camera image data can be utilized by the remote computing system to verify that a change has in fact occurred in response to a change detection signal. Camera image data can further be utilized to generate semantic updates (step210of process200) since low resolution tiles may not have certain information such as color.

In some embodiments, whenever there exists a recent autonomous vehicle drive for an area (e.g., which can include data received from the various sensors, cameras, and lidar of the autonomous vehicle), the remote computing system can then receive and analyze this data (e.g., 3D Tiles302ofFIG.3) and generate updated map assets (e.g., low resolution tiles such as 2D Tiles304ofFIG.3and402,404ofFIG.4) that can then be provided to the autonomous vehicles. In some implementations, the low resolution tiles generated from data from multiple autonomous vehicles can be “stitched” together to provide a view of the area of the detected change to determine whether a change to high resolution tiles are necessary. The updated map assets can further be utilized by autonomous vehicles to supplement 3D maps or high resolution tiles without having to send out autonomous vehicles to capture new 3D maps or high resolution tiles. By utilizing the drive data to generate updated map assets, the remote computing system can lift the avoidance areas in a faster and more efficient manner because detected changes have been accounted for and base maps of the autonomous vehicles updated accordingly.

In change signal methods whether online or offline, an autonomous vehicle drive may already exist and include autonomous vehicle data. For example, autonomous vehicle data can include lidar, camera, or sensor data that was collected from the autonomous vehicle's drive, which may be utilized by the remote computing system to determine any changes in the real world and to designate appropriate semantic labels accordingly. Process200may also include enabling selection of a polygon-based area on the map and generate a low resolution tile. In some implementations, the updated map assets can also be utilized and provided to update semantic labels for any type of task (e.g., issue triage, labelling, etc.) set forth by the autonomous vehicle or remote computing system.

Process200may then advance to step210and generate a semantic update that includes generating semantic data based on the low resolution tile data of step208. For example, the semantic update can include: 2D features such as lane lines, stop lines, cross walks, lane boundary geometry, intersection geometry, etc.; and 2D location of stop signs, traffic lights, curbs, etc. In some implementations, once semantic labels are updated and a base map (e.g., current map version) is not, process200can include maintaining inconsistencies in control by utilizing tracking mechanisms and low priority “redrive” queues (e.g., a list of drives to be performed by autonomous vehicles to remap/scan designated locations). Once the semantic data of step210has been generated, the semantic data can then be directed to step212of process200.

In some implementations, the autonomous vehicle data can include lidar data and session information. For example, the autonomous vehicle data can include lidar data that can be extracted and stitched together. Multiple passes may be performed to stitch the extracted data together. If there are multiple passes, the quality is better because there will be more coverage. However, a single pass is informative and may depend on the type of lidar data collected in that area. The autonomous vehicle data may also include positional information of the autonomous vehicles of the fleet. The same process as described above may be utilized to generate lidar tiles, which may generate a lidar map. The remote computing system may analyze the lidar data (e.g.,302ofFIG.3) and generate a 2D representation (304ofFIG.3,402ofFIG.4), which is a tile. For example, a map tile may be a pixelated version of a lidar point cloud. The map tiles include grids having X-Y coordinates, and a height associated with each pixel. The tile may also include intensity information. For example, as shown in404ofFIG.4, a lane paint line can be seen in a higher intensity compared to an asphalt road, which is why this can be used for labeling.

If recent autonomous vehicle drive data is not available at step206, process200can directly proceed to step212. Step212of process200can include assessing updated map assets from step208or generated semantic updates from step210that may also be related to freshness control. For example, after receiving a change detection at step202, process200can further include proceeding to step214(e.g., high resolution tile tracking), step216(e.g., low resolution tile tracking), and/or step218(e.g., semantic labels tracking) based on the updated map assets from step208or the generated semantic updates from step210. In some implementations, in order to track the freshness of the high resolution tile, low resolution tiles and the semantic labels/features may be updated using either of these assets. The remote computing system may include a tracking scheme that may trigger a service level agreement (SLA)-based task for recollection and refreshing of the high resolution tile (e.g., base map) that may require a redrive. This can be accounted for in the low priority queue in step220of process200.

Low resolution assets generated by process200may utilize an offline pipeline that further includes date and timestamps based on the date of the drive associated with the generation. Feature identification and minisections identification may be updated using the low resolution tile asset to have a log of the assets (e.g., tiles and images) that may be utilized for updating the dates and timestamps. Avoidance areas, as described herein, may be placed to have a log of the assets (e.g., tiles and images) used to place it. Lifted avoidance areas may also be lifted and have a log of the assets (e.g., tiles and images) used to lift it and/or modify it. For example, if a change occurs on November 21 at a particular location, the remote computing system can review all of the files (e.g., data, maps, tiles, labels, etc.) from the autonomous vehicle fleet that have driven within a vicinity of the detected change location, after the change has been detected. In another embodiment, the remote computing system can determine the most recent autonomous vehicle drives and confirm whether or not it has data indicative of the change that was detected. For example, a real world sign was changed on November 1, an autonomous vehicle of the fleet drives past the real world sign on November 5 (but does not detect the change), but then the remote computing system detects the change on November 10. In such an instance, the remote computing system can pull the November 5 data and confirm that it has the data required to update the map data. The remote computing system may then perform process200and run the pipelines as described herein on the autonomous vehicle data that correspond to the area that the change is detected.

In some implementations, as in step214of process200, the remote computing system may determine that a base lidar map (e.g., a high resolution tile) may need to be updated, thereby requiring a redrive of the location in question (e.g., the area surrounding the location of the detected change) utilizing a mapping car. For example, major 3D feature changes detected at step202(e.g., changes to curbs, repavement, speed bumps, or any other major change in the drivable area such as buildings, medians, etc.) may affect a height map for perception and localization, thereby potentially necessitating that the lidar tile assets of the autonomous vehicle be updated. In such a case, process200may proceed to step220, where a redrive queue is updated to include a redrive of the location surrounding the location of the detected change.

The remaining features (e.g., low resolution tiles and semantic labels) of steps216and218of process200may be updated without immediately requiring the update of the high resolution lidar tiles (e.g., of step214) of the base map of the autonomous vehicle. For example, the low resolution tile tracking of step216can include updating low resolution tiles and colorized tiles without requiring the need for a mapping car to redrive the area surrounding the location of the detected change. Moreover, the semantic labels tracking of step218can include updating the semantic labels without requiring the need for a mapping car to redrive the area surrounding the location of the detected change. If the detected change is determined to be a discrepancy by analyzing the autonomous vehicle camera data, a redrive may be entered into the queue of step220for the area surrounding the detected change. If the detected change is determined to be a discrepancy in the data via labeling errors, then a redrive of the area surrounding the detected change may not be necessary and no new map assets may be required. Steps214,216, and218of process200may further occur simultaneously or at different times/stages. For example, a low priority redrive queue of step220can be established or updated for the base map while the semantic labels and/or low resolution tiles of steps216and218are updated independently from step214of process200. In addition, the low resolution tile tracking may store metadata indicative of when the updated low resolution tile data was generated and what assets were used to generate the low resolution tile data. Likewise, semantic label tracking may store metadata of when the updated semantic labels were created and which assets (e.g., low resolution tile) were used to generate the updated semantic label. Process200can further be utilized for 2D semantic features on the map of the autonomous vehicle. With the ability to generate 3D autonomous vehicle tiles, process200can also be utilized to update 3D features such as traffic lights on the map of the autonomous vehicle.

In some implementations, process200can further include step222, which provides the map assets generated by the remote computing system to the autonomous vehicles of the fleet. Step222of process200can also include lifting the avoidance area around the detected real world change so that the autonomous vehicle fleet can enter the avoidance area. For example, signals or messages can be provided to the autonomous vehicle fleet from the remote computing system that include data that designates that the avoidance area may be removed accordingly. Step222of process200can also be facilitated wirelessly, with periodic updates sent to the autonomous vehicles of the fleet. In other implementations, if updated map assets for detected change are available via process200, the updated map assets may be provided to autonomous vehicles that are within a range of the detected change (e.g., within 25 miles of the location of the detected change).

In other implementations, changes in the real world as described herein can trigger investigations by the remote computing system. For example, autonomous vehicle tiles and camera imagery can be received from an autonomous vehicle fleet, which can then be analyzed to determine whether a change has occurred at a particular location. The autonomous vehicle tiles can also be utilized to update semantic features (e.g., semantic labeling), which can then be provided to the autonomous vehicles of the fleet to update features on the semantic map of the autonomous vehicles.

Having disclosed some example system components and concepts, the disclosure now turns toFIG.5, which illustrates an example method500for updating high definition maps based on low resolution map assets. The steps outlined herein are exemplary and can be implemented in any combination thereof, including combinations that exclude, add, or modify certain steps.

At step502, the method500can include receiving, at a remote computing system, a change detection relating to a change in the real world. The change detection can include an inconsistency between the base map of the autonomous vehicle and the real world.

At step504, the method500can include receiving, at the remote computing system, autonomous vehicle drive data based on the change in the real world. The autonomous vehicle drive data can include a timestamp that is before the change detection is received and after the change in the real world. The receiving of the autonomous vehicle drive data can be received from a plurality of autonomous vehicles of a fleet. The low resolution tile data can be stitched together to form the updated low resolution tile data.

At step506, the method500can include generating, by the remote computing system, low resolution tile data based on the autonomous vehicle drive data based on the change in the real world.

At step508, the method500can include generating, by the remote computing system, updated semantic data based on the low resolution tile data generated from the autonomous vehicle drive data, the updated semantic data being generated without utilizing corresponding high resolution tiles mapped from a redrive of a location of the detected change.

At step510, the method500can include providing, by the remote computing system, the updated semantic data to an autonomous vehicle to update a proximate area of the change in the real world of a base map of the autonomous vehicle.

The method500can further include designating, by the remote computing system, an avoidance area over an area proximate to the location of the detected change. Moreover, the method500can also include removing, by the remote computing system, the avoidance area after determining that the updated semantic data addresses the detected change.

FIG.6illustrates an example processor-based system with which some aspects of the subject technology can be implemented. For example, processor-based system600that can be any computing device making up internal computing system110, remote computing system150, a passenger device executing the rideshare app170, vehicle propulsion system130, or any component thereof in which the components of the system are in communication with each other using connection605. Connection605can be a physical connection via a bus, or a direct connection into processor610, such as in a chipset architecture. Connection605can also be a virtual connection, networked connection, or logical connection.

Example system600includes at least one processing unit (CPU or processor)610and connection605that couples various system components including system memory615, such as read-only memory (ROM)620and random-access memory (RAM)625to processor610. Computing system600can include a cache of high-speed memory612connected directly with, in close proximity to, and/or integrated as part of processor610.

Processor610can include any general-purpose processor and a hardware service or software service, such as services632,634, and636stored in storage device630, configured to control processor610as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor610may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

Storage device630can include software services, servers, services, etc., that when the code that defines such software is executed by the processor610, it causes the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor610, connection605, output device635, etc., to carry out the function.

As understood by those of skill in the art, machine-learning based classification techniques can vary depending on the desired implementation. For example, machine-learning classification schemes can utilize one or more of the following, alone or in combination: hidden Markov models; recurrent neural networks; convolutional neural networks (CNNs); deep learning; Bayesian symbolic methods; general adversarial networks (GANs); support vector machines; image registration methods; applicable rule-based system. Where regression algorithms are used, they may include including but are not limited to: a Stochastic Gradient Descent Regressor, and/or a Passive Aggressive Regressor, etc.

Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. By way of example computer-executable instructions can be used to implement perception system functionality for determining when sensor cleaning operations are needed or should begin. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, components, data structures, objects, and the functions inherent in the design of special-purpose processors, etc. that perform tasks or implement abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.