Inventory system

Abstract

An automatic inventory system for a vehicle 100 includes a plurality of containers 104 for holding small items and may also comprise storage 106 for pipes and 108 for cable inventory system for a vehi

Description

The present invention relates to an Inventory System. Technical agents are personnel who carry out installations and repairs at client premises. Installations and repairs are collectively called "jobs" and any one job may require multiple agents. The agents are usually specialists in a particular field such as plumbers, washing machine repairers, electricians, heat-pump installers and so on. These technical agents require both tools and items particular to their speciality such as copper pipe for a plumber, switches for an electrician and so on. One example of a job would be installation of a heat pump heating and hot water system. In terms of agents, this will require, at least, a plumber, an electrician and a heat pump installer. In terms of items, it will require heat pump units, radiators, a hot water tank, control panel and so on. These main items are usually specific to a particular job and may be delivered ahead of time or carried on a vehicle used by the technical agent who will install them. In addition to the main items, an installation will also require a large quantity of other items, which tend to be smaller and / or generic, that is not specific to a particular job. Such items include piping, copper fittings, cable, cable clamps and so on. It is almost impossible to predict the quantities of such items before the installation because pipes and cable may have to follow a more complex routing than expected, items may be damaged and / or the surveying of the job is imperfect. The vehicles used by a technical agent such as a plumber or electrician are known to be stocked with commonly-used items such as pipe fittings, valves, cable, screws and so on. These are either not included on a work order or additional stock is carried to provide some leeway, should the quantities prove inadequate. These are re-stocked from time to time when a vehicle is at a warehouse or depot but the technical agents usually have very little visibility of stock levels. At best they may make a visual inspection of vehicle stock and / or have a vague concept that they are running low on one or more items. These problems are exacerbated when a single vehicle is used by more than one agent. As a result, the agents frequently run out of particular parts in the middle of an installation or repair and have to either travel to a source of more items (such as a warehouse or shop) or re-schedule the job. This has a huge negative impact on productivity, estimated by some organisations to be as much as one quarter, when unproductive driving and waiting time as well as extra travel costs are considered. While services exist, at least in large population centres, to deliver parts at short notice, this can seriously increase both the carbon emissions and the cost of a job, potentially making it economically unviable. Taking a frequent, detailed inventory to prevent running out of items will equally result in a lot of unproductive time. The usual solution to this problem is to over-estimate the quantities required but this means dead inventory being driven around for no purpose with both cost and carbon emission implications. There is also a risk that parts become obsolete and have to be replaced as well as the risk that the agent becomes complacent about the quantities available and still runs out at some point. Novel aspects of the present invention relate to an automated inventory system for tracking items stored in a plurality of containers within a vehicle. However, errors can occur such as an agent or other personnel placing the wrong items in a container. Once this has happened, the utility of the inventory system is severely degraded. It is an object of the present invention to at least ameliorate this drawback. According to a first aspect of the present invention there is provided an automatic inventory system as claimed in claim 1. By further providing an image capture device, the system can automatically track the inventory levels of items that have been placed in the wrong container in the vehicle. This means that the utility of the inventory system is restored. It is important to note that the present invention is distinct from logistics / delivery arrangements in which a precisely known manifest of items is loaded onto a vehicle and either delivered or returned to a depot. Such systems typically require a user to log items going on to and coming off a vehicle, using a QR code or RFID tag per item. A delivery address is provided for each item which may be listed on a printout or on a user device such as a tablet. It is easy to track which items have been delivered and which should still be in the vehicle and / or returned to the warehouse or depot. It is also important to note that the embodiments of the present invention have to operate in an environment of uncertainty in which only some of the items stocked on a vehicle will be removed at a particular time and / or location. Unlike a traditional warehouse location, where items are removed and restocked in accordance with defined procedures, an agent's vehicle stock is hard to track. Items may be removed from a container and some of them replaced later, not necessarily in the correct container. Containers may be removed and not replaced in the same location. Embodiments of the present invention address these issues. The inventory system preferably comprises at least one weighing device per container and the stock level data is preferably weight data. The image capture device preferably comprises at least one camera mounted to the vehicle and more preferably comprises at least two cameras mounted to the vehicle. Alternatively the image capture device comprises at least one camera located on a user device and the inventory engine may further be arranged to instruct a user via a user device to capture at least one image of a container using the user device. If the view of any on-board camera or cameras is obscured, the inventory engine is preferably arranged to instruct the user to capture at least one image. The inventory engine is preferably arranged to compare a plurality of items in the image data with a plurality of images stored in a database to identify which items comprise a first item and which items comprise a second item. The inventory engine is preferably also arranged to identify a rogue item having no matching image in the database. The present invention will now be described, by way of example, with reference to the accompanying drawings, in which: Figure 1 shows the side view of a van to which aspects of the present invention are applied, Figure 2 shows a top view of a van to which aspects of the present invention are applied, Figure 3 shows a side view of a pipe storage tube incorporating aspects of the present invention, Figures 4(a) to 4(c) show views of a storage reel incorporating aspects of the present invention, Figures 5(a) to 5(c) show a front view and block diagrams of a portable parts storage unit, Figure 6 shows a shelving unit and storage containers to which aspects of the present invention are applied, Figure 7 shows a weight sensing unit according to an embodiment of the invention, Figure 8 shows the underside of a storage container suitable for use with embodiments of the invention, Figure 9 shows a block diagram of the weight sensing unit of Figure 7, Figure 10 shows a block diagram of an inventory system for a vehicle according to an embodiment of the present invention, Figure 11 shows a block diagram of an inventory backend system for interacting with a plurality of inventory systems such as that of Figure 9, Figure 12 shows a UI display for reminding an agent regarding high value items, Figure 13(a) and (b) show a UI display for performing a manual update of item quantities, Figure 14(a) and (b) show a flow chart and a UI display for disambiguating contents of containers, Figure 15 shows a schematic diagram of the training and use of a dynamic scheduling engine, Figure 16 shows a perspective view of a container divided into two compartments, Figure 17(a) and (b) shows a UI display warning an agent of having run out, or having low stock, of an item, Figure 18(a) and (b) show UI displays for agent interaction in a rescheduling scenario, and Figure 19 shows a UI display for warning an agent of potential theft from a vehicle. While a number of systems and embodiments are described, the skilled reader will appreciate that these can be deployed individually or in any combination. Figure 1 shows a side view of a vehicle, specifically a van 100 containing a number of parts intended to be used by an agent on a job. A sliding door 102 has been opened to reveal a plurality of parts bins 104, a pipe-holder tube 106 and a cable reel 108. Different vans will be provided with different parts and different quantities of parts depending upon the agent which uses it - plumber, electrician, heat-pump installer, solar panel installer, repair agent etc. Aspects of the present invention envisage that more than one agent and vehicle may be present at a job at a particular time. This means that the stock of more than one vehicle can be considered together implying that a greater range of parts is available. The vehicle or van is licensed to be used on a public highway, for example by a licensed driver, and is not to be confused with robots that can move within a constrained area. Figure 2 shows a plan view 200 of the van of Figure 1 with the roof removed showing a bulkhead 202, a plurality of parts containers 204, a pipe-holder tube 206, a cable reel 208, an RFID reader 210, a store 212 for high value items, a portable store 214, a video camera 216 and a controller 218. The controller is in communication with the RFID reader 210, video camera 216 and other sensors as will be described further below. Figure 3 shows a side, sectional view 300 of a pipe-storage tube 306 containing a number of pipes 308 such as copper pipes having diameters of 15mm and 22mm, for example. The tube 306 can be opened at at least one end 310 to insert or remove pipes therefrom. The tube is suspended from the roof, i.e. ceiling, 304 of the van by a first weight sensor 312 and a second weight sensor 314, which preferably each comprise a load cell. These sensors allow inventory systems according to embodiments of the invention to track the quantity and nature of the pipes within the tube, as will be described further below. The tube may equally be attached to the floor of the van or attached to the roof, subject to sufficient weatherproofing and security measures. It is preferred to provide a pipe-holder tube dedicated to each diameter of pipe to assist in inventory management. This permits the total length of pipe to be determined from the overall weight of pipe within the tube, since an inventory engine will have access to data relating the length of the pipe to its weight. While a pipe tube has been described with reference to Figure, the principle is equally applicable to any elongate material such as lengths of timber and metal fixings. The storage tube may have any suitable cross section and will preferably be at least 5 times as long as it is wide. More preferably, it will be at least 10 times as long as it is wide. When heavier materials such as timber, are stored, suitable load cells can be selected which can sense a higher range of weights. Figures 4(a), 4(b) and 4(c) illustrate alternative cable reel arrangements, each shown as a side view, at least partially in cross section. Each cable reel is shown carrying a few turns of cable. Figure 4(a) shows a side, cross-sectional view 400 of a cable reel 404 mounted to an internal wall of the van such as the bulkhead 402. The reel is supported by an axle 406 about which the reel can rotate and the axle 406 is connected to the bulkhead 402 by a weight sensor 408. The weight sensor, which preferably comprises at least one load cell, communicates a weight reading to the controller (218, Figure 2) to allow inventory systems according to embodiments of the invention to track the amount of cable remaining on the reel 404. The amount of cable or other wound item remaining on the reel can be determined by dividing the weight of the reel by a weight per unit distance of the wound item. The weight per unit distance is preferably stored in a database to which an inventory engine has access. In certain embodiments the weight of an empty reel, or tare, may also be stored and subtracted from the weight of the reel. In many cases, however, the weight of the reel is negligible and can be ignored. Figure 4(b) shows a side, cross-sectional view of part of a cable reel 404 mounted to an internal wall of the van. The reel is supported by an axle 406 about which the reel can rotate and the axle 406 is connected to the bulkhead 402. A distance sensor 410 is mounted above the cable reel 404 and communicates readings to the controller. The distance sensor is preferably an infra-red or ultrasonic sensor which uses time-of-flight (ToF) measurements to determine the amount of cable remaining on the reel 404. This has the drawback relative to the arrangement of Figure 4(a) that further processing is required to determine the amount of cable remaining on the reel since the distance measured by sensor 410 is not linearly related to the amount of cable remaining on the reel. The inventory engine may be arranged to subtract the detected distance from the distance that would be recorded if the reel were empty. This gives the height of the cable remaining on the reel. The amount of cable can then be determined from this using the radius of the empty reel and the number of turns of cable that comprise one layer on the reel. However, the sensor 410 may be cheaper than the weight sensor 408 and may also be mounted such that it is less susceptible to damage than the weight sensor 406. Figure 4(c) shows a side, cross-sectional view of part of a cable reel 404 mounted to an internal wall of the van. The reel is supported by an axle 406 about which the reel can rotate and the axle 406 is connected to the bulkhead as before. A rotation sensor 412 is mounted next to the cable reel 404 and communicates readings to the controller. The rotation sensor is preferably an optical sensor for allowing the number of rotations made by the reel 404 to be counted. The optical sensor is conveniently a light gate. This rotation sensing has the same drawback as the arrangement of Figure 4(b) that further processing is required to determine the amount of cable remaining on the reel since the number of rotations detected by sensor 412 is not linearly related to the amount of cable remaining on the reel. However, the sensor 412 may be mounted such that it is less susceptible to damage than the weight sensor 406. Multiple sensors, such as light gates, may be mounted around the reel or a single sensor may identify multiple points on the reel. This permits the inventory system to identify less than one turn of the reel to improve accuracy. The multiple sensors or multiple sensed points are preferably located equidistantly around the circumference of the reel. Additionally, or alternatively, a sensor 414 may comprise a magnetic sensor such as a Hall effect sensor which requires a magnet 416 to be mounted to the reel 404. In a preferred embodiment, at least one optical sensor and at least one magnetic sensor are provided to enable redundancy of sensing. These sensors are preferably located equidistantly around the circumference of the reel. For example, a light gate may be mounted at 0 degrees and a Hall sensor mounted at 180 degrees. Figure 4 shows an electrical cable reel but the principles described are equally applicable to other components that are supplied on reels such as wire and plastic plumbing pipe (collectively "wound items"). The inventory engine may be arranged to send a message to a user device in response to the quantity of wound item falling below a threshold. Figure 17, described further below, illustrates a type of such message. Figure 5(a) shows a partially sectional front view 500 of the portable store 214 of Figure 2. The store comprises a case 502 containing 4 drawers 504 and further comprising a pair of wheels 508 and a handle 506. Each drawer may include up to 10 or even 20 containers or other boxes. A control unit 510 incorporating a distance sensor is mounted within the case 502 on the underside of an upper panel thereof. The distance sensor is arranged to determine the contents of the store. Alternatively, or in addition, the weight of the portable store can be measured by a weight sensor 512 to determine the total weight of the store. The weight sensor may be mounted to the portable store or mounted to the vehicle such that it bears the weight of the portable store when the store is in the vehicle. The contents can be determined using one or more disambiguation techniques described below. Figure 5(b) shows a block diagram of the portable store comprising a controller 520 which connects via a plug 522 to a docking station in the van. The docking station is connected to the controller (218, Fig. 2) to obtain power for a battery 524 and to convey inventory data determined by a distance sensor 526 and stored in a memory 530. Aweight sensor 528 may be provided in addition or as an alternative to the sensor 526. The controller 520 is arranged to take measurements from the sensor 526, store these measurements in the memory 530 and convey them to the main controller in the vehicle when the connector 522 is attached to the docking station. The battery 524 will also be charged when the portable store is docked. A drawback of the arrangement shown in Figure 5(b) is that a docking station is required to connect to the main controller in the vehicle. A tradesperson's van can be a harsh environment and damage or contamination of the docking station or connector 522 may occur. Figure 5(c) shows a block diagram of an alternative circuit for the portable store which communicates wirelessly with the controller in the vehicle. In this embodiment, the controller, memory and one or more sensors operate in the same manner as for the previous figure. Without a physical connection to the vehicle docking station, the circuit will need means to charge or replace a battery. Although a replaceable battery could be used, this embodiment further comprises a generator, such as a dynamo 540 connected to one of the wheels 508 of the portable store. While the store is being wheeled around, the battery 524 will be charged. A transceiver 542 is also connected to the controller 520 and operates, under the control of the controller, to convey data to the main controller in the vehicle. The transceiver 542 is preferably an RFID tag and the transmission of data to the main controller in the vehicle is described below. While a portable store comprising several drawers has been shown, the store may comprise a single container or bucket into which an agent may place items that he or she expects to use on a job. The store may be provided with a weight sensor such as the sensor 512, 528. This sensor may be mounted to the portable store or may be mounted to the vehicle which then requires the portable store to be placed in the same position each time. The output of the weight sensor is communicated to the inventory engine. Another alternative is a modular arrangement comprising individual storage units which may be coupled together. In one arrangement, a first unit is stacked on top of a second unit. Under each unit is a weight sensor. The first weight sensor under the first unit measures the weight of the first unit while the second weight sensor under the second unit measures the weight of both the first and second unit, together with the weight of the first weight sensor. The inventory engine is arranged to subtract these weights to determine the weight of the second unit. The principle can be extended to further modular units and weight sensors. The inventory engine may be arranged to determine the contents of the portable store by comparing items removed from other containers in the vehicle with increases in weight detected at the portable store. For example, if three items weighing 15g each are transferred from a container in the vehicle to the portable store then a 45g increase in the weight of the portable store will be detected. A time limit may be placed on the transfer, such as 5 seconds. The inventory engine will not determine that items have been placed in the portable store, even after being removed from a container in the vehicle, if the weight of the portable store does not increase by a commensurate amount. The inventory engine may be triggered to commence this determination due to a change of weight of the portable store and / or image data received from a camera in the vehicle. Figure 6 shows a perspective view 600 of a shelving unit for holding removable containers such as the containers 104 (Figure 1). The shelving unit 602 includes three bays into which a container 604 may be placed. Two such containers are present in the figure while the third bay 606 is empty. Any number of bays may be provided in any configuration with 5 shelves of 6 containers each being a preferred layout. The bays are provided with short upstanding sides 608 to hold the containers 604 securely, while allowing them to be removed easily from the shelving unit. The containers may be removed from either the front or back of the shelving unit. Within the bays is a weight sensing unit 610 which comprises a plurality of load cells and an RFID reader. The RFID readers associated with the storage locations, or bays, are preferably arranged to operate at a different frequency from the general RFID reader or readers (210, Figure 2). Figure 7 shows an underside perspective view 700 of the weight sensing unit 610 (Figure 6). A rectangular platform 702, upon which a container sits, carries a centrally-mounted control circuit 704 coupled to four load cells 706 located at the corners of the platform. The control circuit 704 is also connected to the main controller (218, Figure 2) in the vehicle and comprises an RFID reader to read an RFID tag mounted on the bottom of the container. Alternatively, the load cells 706 and the RFID reader may be connected directly to the main controller (218, Figure 2, 1002, Figure 10). In either case, the circuit board and / or the main controller may be arranged to combine the outputs of the load cells (such as by adding the output together). Another possibility is for a load cell to be arranged as a four-part half bridge load cell which provides a single reading which is easier to calibrate. Alternatively, the controller may send the individual outputs to the inventory engine which has advantages for disambiguation as described further below. The RFID reader is arranged to operate over a very short range so that it can only communicate with a container directly above it on the platform 702. Figure 8 shows an underside perspective view 800 of a container 802. In the centre of the base of the container is mounted an RFID tag 804 which is used to identify which container is located in a particular bay (606, Figure 6). The RFID tag is preferably mounted within a recess or enclosure in the base of the container to protect it from damage. When the container is placed in a bay (610, Figure 6) of the shelving unit, the RFID tag 804 will be directly above the RFID reader incorporated in the circuit board 704 (Fig. 7). Alternatively, container identification could be performed by using an optical code such as a QR code. A QR code mounted on the container would then be read by an optical reader such as a camera located close to the container. The skilled person will appreciate that the weight sensing unit may be incorporated with the container in an alternative embodiment. The RFID tag on the container can then be used to convey both the identity of the container and the weight measurements. The necessary circuitry can be powered by a small battery and / or via a power coupling to the shelf or bay on which it is located. Figure 9 shows a block diagram 900 of the weight sensing circuit (610, Figure 6). A controller 902 is connected to an RFID reader 904 and to four load cells 906. The load cells may comprise GML624 load cells available from GALOCE at www.galoce.com. The controller 902 comprises an analogue-to-digital converter (ADC) to convert the analogue output of the load cells to digital signals which are stored in a memory of the controller. The controller is connected to the main controller (218, Figure 2) in the vehicle by a bus 908 which also provides power to the weight sensing circuit. When instructed, the controller performs weight sensing and RFID tag detection and sends the following information back the main controller: identity of the weight sensing unit (preset, for example using DIP switches) identity of the container (read from RFID tag or QR code) weight data for the container (which may include all four load cell readings) The communication with the main controller may be performed in any suitable manner such as RS485 signaling over a MODBUS protocol. The weight sensing circuits are preferably connected to the bus 908 in a daisy chain to minimize wiring within the vehicle. In one embodiment, the load cells are bridged at the weight sensing circuit in a Wheatstone arrangement to provide a single analogue signal to the ADC of the controller. In another embodiment, where the controller is arranged to read the load cells individually, the controller preferably connects each load cell in turn (multiplexing) to the ADC to reduce the circuitry required in the controller. The controller may be implemented by a suitable programmed microprocessor, an ASIC, a FPGA and so on. In some embodiments, the weight sensing circuit may be omitted and the sensor or sensors connected directly to the controller. The weight sensing units are preferably only activated when a weight reading is being performed to optimise power consumption. Figure 10 shows a block schematic diagram 1000 of the portion of the inventory system located in the vehicle. Power supply connections are not shown since it is expected to operate the system from vehicle power sources such as a 12v circuit or a 5v circuit such as from a USB socket. The system is suitable for both combustion engined vehicles and electric vehicles. A main controller 1002 is provided with a memory 1004 and a cellular transceiver 1006 for communicating with a backend to be described below. The controller is further connected to various accessories as follows: weight sensing circuits 1008 upon which containers may be located pipe tube weight sensing circuit 1010 cable reel sensing circuit 1012 ignition sensing circuit (is the ignition on i.e. van ready to move?) 1014 accelerometer (is the van moving?) 1016 attitude sensor (what angle is the vehicle at from front-to-back and / or side-to-side e.g. is the van on a slope?) 1018 door sensor 1020 GPS sensor 1022 - RFID reader 1024 Camera 1026 Docking station for portable storage unit 1028 Reset or restocking button (to alert the controller to restocking) 1030 These accessories may be provided in any combination. For example, the docking station for the portable storage unit may be omitted if the embodiment of 5(c) is utilized. Certain sensors may already be provided on a vehicle as part of its telemetry system such as a GPS sensor and an accelerometer which may be read, for example, via the vehicle's diagnostic port to avoid having to provide a further sensor. It is generally preferred to include the sensors as part of the inventory system, however, since that will avoid incompatibility and regulatory issues. The skilled reader will be able to select the most appropriate interface between each of these accessories and the controller. The weight sensing circuits include both load cells and the RFID reader for identifying the container placed upon them. These are preferably connected to the controller 1002 using RS485 / MODBUS as discussed above. The pipe tube and cable reel sensing circuits may also be connected in this manner. The controller 1002 stores in memory 1004 a table such as the following Vehicle ID BD21ETG Location E15DG Attitude Level Container ID Load cell ID Weight / gram Total weight / g Timestamp New value 001 1000 51.2 231.6 10:05:21 Y 1001 47.1 1002 71.0 1003 62.3 002 1008 98.1 719.2 10:05:29 N 1009 104.0 1010 106.9 1011 101.2 003 PIPE TUBE 3.23kg 10:10:14 N CABLE 2.8kg 10:12:01 N Quantity of high value items Pump 2 N Drill / Driver 1 N The New Value column tracks whether the weight has changed since the last measurement (by comparing any new measurement with the previous value before it is overwritten). This allows the controller to only transmit changes to weight values to the backend. Note that the contents of the containers are not necessarily known to the controller, i.e. there is no requirement for a description or stock keeping unit (SKU) number associated with the weighing apparatus. What the controller does detect is which container is placed on which weighing apparatus since there is no guarantee that an agent will always place the same container on the same weighing apparatus. The weight field may comprise four values as shown (one for each load cell) or it may comprise a single value derived from the output of the four load cells. The per-load cell information may then be made available to the backend for disambiguation and other purposes as described below. Since this will necessitate a slight increase in data transmission, in some embodiments it is preferred to combine the outputs of the load cells locally (whether using a Wheatstone bridge prior to ADC or digitally at the weight sensing unit or the controller). The further sensors connected to the controller may be activated as required or instructed by the backend (described below) via the cellular transceiver 1006. Two types of RFID reader In preferred embodiments, at least two types of RFID tag reader are provided within the vehicle: specific and general tag readers. The specific tag readers are located close to removable containers such as parts bins. They are intended to read only the tag on the closest container. The general RFID tag reader 1024, or readers, is intended to read other tags in the vehicle. This allows inventory systems according to preferred embodiments of the invention to further track specific items, typically high value items such as pumps and power tools (see table above). The general RFID tag reader may also be used to receive data from the wireless embodiment of the portable store (Figure 5(c)). The general tag reader or readers are preferably arranged to detect only RFID tags located within the vehicle. The range of the general RFID reader is preferably selected to read only RFID tags within the vehicle. A problem may arise when a vehicle is close to another vehicle or store of parts at a job site or when the vehicle is located close to a warehouse or parts retailer. This problem may be reduced by providing a RFID reader with a directional antenna located at an upper corner inside the vehicle. Alternatively, or in addition, the inventory engine may be arranged to ignore tags corresponding to parts that are not intended to be on a particular vehicle. In embodiments having a general tag reader, the table above can be suitably modified to include both a tag ID as well as quantities of items detected by such reader. Details of items identified by the general tag reader may be stored in a separate table if desired. While Figure 10 includes a cellular transceiver to communicate with the inventory engine, the skilled person will appreciate that other radio transmission technologies may be employed. Figure 11 shows a block diagram 1100 of a backend according to certain embodiments of the present invention. The backend includes an inventory engine, a scheduling engine and a survey engine together with a database and various interfaces. Not all embodiments of the invention will include all of these features. The skilled person will appreciate that the backend functionality may be provided by a cloud service. Features common to cloud computing environments have been omitted for clarity. For example, log in procedures may be executed by any suitable service, such as Cognito™. A cellular interface 1102 is in wireless communication with an agent's device 1104 and a warehouse staff's device 1106 (collectively, user devices) each of which has a relevant app loaded. These are purely exemplary - in practice there will be many more devices. The cellular interface is also in communication with a plurality of vehicles 108. The cellular interface is connected via the Internet 1110 to an inventory engine 1112. The inventory engine is also connected via the Internet 1110 to a web server 1114 and a computer 1116 to provide an alternative interface to the agent and warehouse staff's devices. The inventory engine is also connected to a purchasing interface 1118 that tracks purchases made by individual agents using a company card or company account and to machine vision unit 1120. The backend includes a database 1122containing both van stock job information. The database is also connected to a survey engine 1126 and a scheduling engine 1128. While a single database is shown, several databases may be provided and connected to one or more of the inventory engine, survey engine and scheduling engine. The fundamental purpose of the backend is to automatically track inventory for all vehicles in the fleet but it is preferably further arranged to perform further operations to improve inventory control and agent utilization throughout the inventory system. Tracking vehicle stock The inventory engine 1112 receives data, over the cellular network, from a plurality of vehicles and maintains the vehicle stock database 1122 containing general fields and part-specific fields for each vehicle such as: Vehicle BD21ETG Agent John Cain Agent type Plumber Location 51.5N, 0.12W Stock SKU Description Item Weight Bin weight Quantity End of life 123456 15mm Elbow 12.2g 207g 17 n / a 654321 Pump n / a n / a 2 n / a 456123 15mm pipe 778g 3.9kg 5 n / a 345123 Insulation panel n / a n / a 4 n / a T123 Drill / driver n / a n / a 1 31-08-2025 General fields shown include the vehicle identity, agent name, agent type and location of vehicle but further fields may be included as appropriate, such as employee number, current job, charge level of vehicle battery and so on. The part-specific fields include a stock keeping unit, human-readable description, item weight, bin weight, quantity and end-of-life but not all fields will be appropriate or available for all items. Further fields may be added to record a previous weight or quantity, a timestamp indicating the point when a change was detected or an image of the item. The latter may assist warehouse personnel who are not skilled tradespeople with identifying correct parts. The first and third items in the table are stored in the containers (104, Figure 1) which are weighed to provide inventory data. These items are too small or too cheap to be provided with their own RFID tag. The second item is a higher value item that is provided with an RFID tag which is read by the general RFID reader in the vehicle and so its weight is irrelevant for inventory purposes (although it may be stored to ensure that vehicles are not overloaded). The fourth item is one which is neither measured by weight nor has its own RFID tag. Quantities of such items, which are generally bulky, are reported by the agent as discussed further below. None of the first, second, third or fourth items have a shelf life or use-by date. The fifth item is a T123 drill / driver power tool used by the agent. It is provided with an RFID tag and identified in the same manner as item number 2. Health and safety concerns mean that such a tool has a finite life and must be maintained and / or replaced. The inventory engine will monitor the end-of-life date and alert the agent and / or warehouse personnel that the item is to be replaced (or perhaps subject to a periodic safety test such as a Periodic Appliance Test (PAT) in the UK). Data relating to tools may be stored in a separate table or database. In use, the inventory engine will receive regular (push) updates from individual vehicles. These can be triggered by the vehicle door(s) being closed, the vehicle arriving at a specific location such as a warehouse, by the engine of the van being switched off and so on. The controller on the vehicle will "wake up" in response to a preprogrammed event and instruct the various weight sensing units to perform the required measurements and store the results in local memory. Once all of the measurements have been performed, the controller will transmit the weight values to the inventory engine over the cellular network. Typically, the transmission will be limited to weights of containers that have changed since the last measurement in order to reduce the amount of data being transmitted over the cellular network. For example: "Container ID = 1, Load cell ID = 1001 to 1004, 12.1g, 13.6g. 9.9g, 14.4g". Other formats, such as more compact formats, are possible and some degree of error detection and correction may also be implemented ahead of the radio transmission. The inventory engine may also instruct the controller in a specific vehicle to perform a (pull) update on a certain container or containers, or to search for a specific item using the vehicle's general RFID tag. This functionality may be used when the inventory engine is searching for one or more items to provide to another agent who is low on stock, to be described further below. The inventory engine may also be arranged to instruct a controller in a vehicle to perform a complete inventory check to obtain a pull update. Such a check may be performed after a re-stock of the vehicle or after a job or series of jobs. Instead of transmitting weight data to the inventory engine, the controller in a vehicle may transmit another parameter such as the number of items or percentage fullness for a particular container. The determination of the parameter from the weight values must then be performed at the vehicle controller. This may decrease the amount of data to be transmitted but has the disadvantage of requiring further processing at the vehicle controller. Warning of missing item(s) in the vehicle In one embodiment, the inventory engine is arranged to warn an agent or other user that an item has been left behind at a job or other location. The inventory engine is preferably responsive to a vehicle condition such as a door being closed, a key being inserted, an engine being started and so on. The inventory engine may, alternatively, respond to expiry of a time period. The inventory engine is arranged to identify items removed from the vehicle after arrival at a location but not returned before departure from the location. Some items used on the job will, of course, remain at the job location. However, other items such as tools or surplus stock should be returned to the vehicle. The inventory engine is thus arranged to identify whether any of the removed items should have been returned to the vehicle. When such items are identified, and are absent from the vehicle at a point where it appears that the agent is leaving the job, the inventory engine will send a message to a user device associated with the vehicle, such as the agent's phone. Figure 12 shows an exemplary display on a user's device. In order to determine whether items should return to the vehicle, the inventory engine is arranged to compare the removed items with a predetermined list, such as an inventory of parts for a job. The inventory of parts may be generated by the inventory engine using a comparison with the items required for a previous job In another embodiment, the inventory engine is arranged to ensure that tools are returned to the vehicle, such as from a list of tools. Even if the agent is intending to return to the job after lunch or the next day, this will reduce the risk of theft. The tools (and other larger items) are provided with RFID tags which are read by the general RFID reader in the vehicle. Updating miscellaneous inventory Certain items carried in the agent's vehicle will neither fit into a container nor are valuable enough to warrant an individual RFID tag. These are referred to as miscellaneous items and will typically be bulky items such as insulation panels and containers of central heating inhibitor. In order to maintain an accurate record of such items, a specific query may be made by the inventory engine to the agent via the app as shown in Figure 13. Figure 13(a) shows the first display which invites the agent to update the miscellaneous material and gives the option to defer the update. Assuming that the agent is happy to proceed with the update, subsequent displays provide the agent with the possibility to update the quantities stored by the inventory engine in the vehicle parts database. Figure 13(b) identifies, as an example, insulation panels that are not automatically tracked by the system. The inventory engine instructs the agent's device to prepopulate the display with the last known, or current estimated quantity for each item. An image of the part may also be displayed. In this example, the backend records show that there should be 7 insulation panels on the van. The agent is provided with buttons to increase or decrease these quantities as appropriate and this information is sent over the cellular network to the inventory engine. The agent may press a "next" button to proceed to the next screen. An update of miscellaneous quantities could equally be initiated by the agent, for example at the end of a job or if stock or particular parts is running low. Disambiguation In some embodiments of the invention, the inventory engine is further arranged to perform disambiguation for items in a vehicle. The accuracy of the inventory system relies upon the behaviour of the agent, for example to ensure that all items of a particular type are in the correct container and that the containers do not contain inappropriate items. However, mistakes occur and this is likely to cause errors in the inventory system. For example, if a spanner is left in a container for 15m elbows then it could appear that a large number of elbows has been added to vehicle stock. If 22mm elbows are placed in the container for 15mm elbows, then when the inventory engine attempts to convert from load cell weight readings to numbers of parts, the answer will be wrong and also usually be ambiguous. The inventory engine may thus be arranged to detect such anomalies in response: 1. to an increase in weight while the vehicle is not being re-stocked 2. to an increase or decrease in weight by an amount that is not an integer multiple of the item weight Care is required in case 1 because some agents will remove a large number of items from containers and take these into the premises, possibly using a portable store such as that shown in Figure 5. Those items that are not used may be returned to the container at the end of the job, causing an increase in container weight. One approach to disambiguation is for the inventory engine to obtain data from another source. One such source may be an image of the container obtained from a camera mounted in the vehicle. The inventory engine may then instruct the machine vision unit to determine whether alien parts have been placed in a container. Alternatively, the inventory engine may request the agent to provide an image of the relevant container or containers using the agent app. The agent may immediately identify the problem, resolve it, and inform the inventory engine. The inventory engine may then repeat the attempt to measure the inventory. Figure 14(a) shows a flow chart of an exemplary series of steps. The process starts at step 1400 and proceeds to step 1402. At step 1402 the inventory engine performs the calculations to convert the weight readings from the controller in the vehicle to a quantity of the relevant items. At decision step 1406, the inventory engine determines whether the result is reasonable, for example based on previous quantities, weight of the expected items and current expectations. If the result is acceptable it is stored in the vehicle stock database at step 1408 and the process ends at step 1410. If, at step 1406, the result of the calculation is not within an acceptable range or throws up another anomaly, then one or more images is requested from the controller in the vehicle at step 1412. The camera in the vehicle may be a pan-tilt-zoom (PTZ) device which can be focused on the anomalous container. At step 1414 the inventory engine provides the at least one image to the machine vision unit to identify the cause of the error. The machine vision unit may make a comparison between the current image and a previous image or may compare items in a container with pre-stored images. Either comparison may allow the machine vision unit to identify the cause of the anomaly and communicate this to the inventory engine. At step 1416, the inventory engine determines whether the cause of the anomaly has been determined by the machine vision unit. This may be performed by way of a convolutional neural network (CNN) classifier trained to identify the presence of an anomalous object. If it has, processing proceeds to step 1418 in which the anomaly engine informs the agent via their device how to address the problem. If the cause of the problem is still unclear, the processing proceeds to step 1420 in which the anomaly engine asks the agent to identify the problem. In either case, processing then proceeds to step 1422 in which the inventory engine requests new weight readings from the vehicle controller and the calculation repeated at step 1404. Figure 14(b) shows an app display for an alternative embodiment of the disambiguation technique. Upon detection of an anomaly, the inventory engine identifies the problem to the agent for example "Container 4 appears to contain rogue parts. Please remedy the fault or take a photo." This also addresses the case in which the vehicle does not have a suitable camera to provide an image of the anomalous container. Another disambiguation technique does not rely on a further information source would comprise: A training dataset which is collected over time and composed of weight change events, including for each: - job type ■■ job progress (e.g. 20% complete) - job location - time of day ■ installer name ■ weight change ■■ components or items used Based on this training dataset, a classifier is trained to predict what component has been used based on the weight change measured as well as the job type, progress, etc. Options for the classifier would be Naive Bayes, Random Forest, Gradient Boost and Artificial Neural Network (ANN). Given the number of installers, it may also be sensible to implement a clustering process (e.g. a supervised technique such as KNN-clustering) to identify a reduced number of "event types", essentially grouping together similar installers and job types. The classifier could be continually retrained as new data is ingested. Figure 15 shows an arrangement 1500 for the training of the machine vision unit 1502. Although the machine vision unit 1502 is shown separately, the unit may be implemented as an Artificial Neural Network (ANN) or Convolutional Neural Network (CNN) that forms part of the inventory engine. The machine vision unit is trained using images of items that may be stocked in an agent's vehicle. The vehicle stock database 1504 provides the identity and at least one image of all of the possible items which may be stocked in a vehicle. Also shown in the figure is an optional database 1506 comprising a retailer catalogue. Where the vehicle stock database does not include suitable images, the training images may be readily obtained from online catalogues such as those of a parts manufacturer or retailer. In a preferred embodiment the machine vision unit is trained using at least two different sources of images for the same item. Since the images of items may be oriented differently in practice from those shown in the training images, the training images may optionally be re-oriented using an image processor 1508. The machine vision unit 1502 is thus subject to several images of each item from a different perspective to improve recognition in use. Multi-item containers In another application of disambiguation, different items may deliberately be kept in the same container. Such items will typically be lesser-used items that do not warrant their own container on the vehicle. The inventory engine may be arranged to determine the quantities in such a container as follows. Imagine, for example, a container contains two different parts: part A weighs 20g and part B weighs 72g. The weight of items in the container W therefore equals: W = 20A + 72B Where A and B are the quantities of the respective parts in the container. The inventory engine, presented with a total container weight of 204g can therefore determine that there are two items Bs and three item As. This permits fewer containers to be provided, saving space and cost. The principle can be extended to three, four or more items stored in a single container, subject to them having distinguishable weights. However, in certain circumstances this method of disambiguation may fail. For example, when quantities of one or both parts are greater, 5 part Bs weigh the same as 18 part As (360g). One possible remedy is to base the disambiguation on the change of weight in the container (rather than the absolute weight). Imagine that the weight of the container reduces by 40g. This can only result from removal of 2 part As. If the weight increases by 72g, this can only be due to restocking or replacement of one part B. The items that are selected to share a container are preferably selected on the basis of their weights. The inventory system will consider the weights of all possible products that are to share a container and select pairs of items that are easiest to disambiguate. This disambiguation technique is particularly applicable to the pipe-holder tube of Figure 3 in which a 15mm copper pipe will typically weigh 0.84kg per 3m length and a 22mm copper pipe will typically weigh 1.59kg per 3m length. Another approach is applicable to a container that includes a divider. For example, the front portion of the container contains a first part and the rear portion of the container contains the second part. Figure 16 shows a cutaway perspective view 1600 of a container 1602 and weighing device 1604. The weighing device includes 4 load cells 1606, 1608,1610, 1612 as before but the container 1602 is provided with a divider 1614 to isolate parts 1616 in the front half of the container and parts 1618 in the rear half of the container. The parts 1616 in the front half of the container will affect the load cells 1606, 1608 much more than they will affect load cells 1610 and 1612. The parts 1618 in the rear half of the container will affect load cells 1614, 1616 more than they will affect load cells 1610 and 1612. This provides the inventory engine with further means to disambiguate the contents of the container 1602. Further possibilities include using historical disambiguation or dynamic disambiguation in which the vehicle is moving and both of these are discussed further below. It is still possible that the inventory engine may, from time to time, lose track of the inventory in a shared container. In this circumstance, the inventory engine may pose an explicit query to the agent similar to the miscellaneous item query discussed above with reference to Figure 13. Identify supplier from weight information In some circumstances it may be necessary to identify the supplier of particular items, for example if there is a recall of faulty stock. An item, such an a 22mm elbow joint is available from two different suppliers. The first supplier's parts weigh 5.6g each and the second supplier's parts weigh 5.9g. The inventory engine may exploit this information to identify which vehicles contain items from the two manufacturers. Where a container contains a mix of parts from different suppliers, the inventory engine can calculate the respective quantities. Dynamic disambiguation In general, the inventory system in the vehicles is arranged to weigh the containers only when the vehicle is stationary. However, the inventory engine may be arranged to request weight data ("dynamic weight data") from a vehicle while it is moving. Movement of the vehicle and bumps in the road will cause the items in a container to shift, causing the container to appear heavier or lighter at different points in time. By instructing the inventory system to perform weight measurements dynamically, the inventory engine can gain extra data to identify the contents of a container. Thel6nventtory engine may easily be trained to operate in this mode. Training data is readily available since accurate inventory for most of the containers in most of the vehicles is available in the vehicle parts database. By instructing the vehicle controller to obtain dynamic weight data for such containers while the relevant vehicle is moving, the precise dynamic behaviour for each part may be determined and stored. This dynamic weight data is preferably derived and stored together with accelerometer and / or attitude data for the vehicle. This trains the inventory engine to identify the relationship between the apparent fluctuation in the weight of certain items and the vertical acceleration of the vehicle. In use, the dynamic weight measurements are compared with the statically-derived values in respect of weighing device / container combinations with anomalous outputs. The inventory engine can then identify the source of the problem by comparing the behaviour, such as the resonant frequency of the correct parts in a container with the behaviour of the alien parts. The inventory engine may also exploit historical data to perform disambiguation. Imagine at a time t6 there is a change which might be due to 6x item A and 2x item B or 2x item A and 3x item B. Initially, at a time to in the past, there were 23 part A's and then at subsequent times t2, t3 and t5 the inventory engine determined that 5, 10 and 6 item A's respectively were removed. At time t6, therefore, there could only be (23-5-10-6) i.e. 2 item A's remaining. The items taken at time t6 were thus 2 of A and 3 of B (since there were not enough item A's left for 6 to have been taken). Disambiguation using another source In another embodiment, the inventory engine is arranged to disambiguate the contents of a container by correlating the anomaly with other sources of data. These other sources may include: comparing an anomalous weight increase with other parts known to be present in the vehicle comparing an anomalous weight increase with other parts known to be present in a restocking operation comparing an anomalous weight increase with other parts known to have been purchased from a retailer (using the agent's card or company account) comparing an anomalous weight increase with other parts known to be present in another vehicle from which items are being transferred (running out of items - see below) Note that the above-described disambiguation techniques may be used in any combination. Disambiguation training In another embodiment, the inventory engine is explicitly trained to detect anomalies using data collected from at least one vehicle. The inventory engine comprises a classifier, such as Naive Bayes, Random Forest, Gradient Boost or Artificial Neural Network (ANN), The classifier is trained using a plurality of reference files. Each reference file contains a description of an anomaly and the stock level measurement or measurements that result from it. To generate the reference files, personnel are explicitly requested, via user devices, to create anomalies. A message to personnel might be "place a 10mm spanner in bin 7". The inventory engine then instructs the inventory system on the vehicle to perform a measurement in respect of bin 7 and adds the result to the reference file. Once the classifier is trained, the inventory engine may then be applied to use the classifier to identify anomalies and instruct personnel to remedy them. Such a message may be "remove 10mm spanner from bin 7". The anomaly may comprise placing a socket in a container, as such a tool is hard to located among items in a container. The anomaly may comprise placing an incorrect item or even a plurality of different incorrect items in a container. In addition, once the classifier is suitable trained, as described above, it may be used to locate a lost item. A user may request the location of a lost item or tool from the inventory engine using their user device. Such a message may be "lost 10mm spanner in vehicle BD21 ETG". The inventory engine is then arranged to identify the weight of the misplaced item and to instruct a measurement of stock level in respect of a plurality of containers. These measurements are then each compared with a previous stock level to identify a stock level that has increased by the weight of the misplaced item. The inventory engine then communicates with the user device to inform a user of the location of the misplaced item, for example "The 10mm spanner is located in bin 7". This process may, of course, identify further anomalies that can be communicated to the user. Training in anomaly detection may also be performed using weighing event data from a plurality of vehicles. From the historical data, the inventory engine can determine that for a given agent type, on a given job, there is an expectation of certain events occuring. If it's outside a likely threshold then an anomaly is flagged. Similar looking anomalies can be combined by clustering. Diagnosing the anomaly types would probably then need the training approach you have described. Dynamic or in-field re-stock Multiple vehicles within a given geographical area may be considered so that if one agent is low on stock of a particular item that they need, then they may be able to obtain stock from a nearby vehicle rather than have to return to warehouse (or other source of parts) or postpone the job. The inventory engine is arranged to identify the location of the vehicles and treat a number of vehicles within a geographical area as a dynamic warehouse. Exemplary steps of the process are: 1. Low (or no) stock in a vehicle is identified, either by way of an explicit request from the agent or automatically by the inventory engine 2. The inventory engine checks the stock of vehicles within a particular geographical radius or travel time from the vehicle with low stock 3. The inventory engine identifies those vehicles with suitable stock 4. The inventory engine optionally identifies other sources of stock such as local retailers 5. The inventory engine identifies the most appropriate source of replacement stock, generally being the closest vehicle with available stock It is important to ensure that the vehicle from which stock is removed can spare the item or items removed. Otherwise, that vehicle will then have a difficulty with shortage of items. Once a source of stock has been identified, the inventory engine will inform the agent associated with a second vehicle (that requires an item) of the location of a first vehicle (that can provide an item). The inventory engine then monitors their respective locations and, once they are in the same place, monitors whether the handover has occurred. This can be performed by the inventory engine instructing a measurement of stock level at the first vehicle and the second vehicle in respect of that at least one item. If the handover has not occurred (i.e. if the stock level of the first item in the first vehicle has not decreased or the stock level in the second vehicle has not increased), the inventory engine is arranged to communicate with a user device to remind the user to perform the transfer. Alternatively, the agent associated with the first vehicle may be informed of the location of the second vehicle. That is to say, the donor vehicle travels to the recipient vehicle rather than the other way around. Where the closest first vehicle does not have adequate stock (e.g. because it is for a different type of agent or all relevant stock is required for scheduled jobs) then the inventory engine will identify further possible vehicle or vehicles to provide the item(s). The inventory engine preferably includes a consideration of carbon emissions in identifying suitable first (donor) vehicles. Figure 17(a) shows an image from an agent's device informing an agent that they have no stock of 15mm elbows on their vehicle. Figure 17(b) shows an image from an agent's device warning them that they have low stock of 15mm elbows on their vehicle. A "Restock Now" button is also provided in both cases in the app. The agent may know that they do not need any 15mm elbows in the foreseeable future and so may ignore the warning. However, if the agent does need this part imminently then they can press the Restock Now button. This message is received at the inventory engine and the series of steps above ensues. In another embodiment, the inventory engine also marks a restocking record for the vehicle so that 15mm elbows are loaded onto the vehicle when it is next re-stocked at a warehouse. The messages shown in Figure 17 may, of course, be varied to apply to any other item stocked on a vehicle. For the immediate re-stocking, the most appropriate source of stock is preferably selected as that which has the lowest carbon emissions. The most favourable outcome, with the lowest carbon emissions, will be if another vehicle, which is at, or destined for, the same job, has the required stock. Another option to obtain replacement stock is to deliberately load the stock onto another vehicle which is destined for the same job. These options will usually have the lowest carbon emissions. Another option is to divert a vehicle headed to a different job to provide the relevant stock. In this case the inventory engine can confirm that the transfer has occurred by issuing requests to each vehicle controller and comparing the stock levels in each one. If the stock has left one of the vehicles but not arrived at the other, then the backend can message the recipient agent to ask why. In a repair scenario it can be rather more difficult to predict which part or parts may be required to effect the repair. Often the only information available to the inventory engine will be a symptom reported by the occupier which may be very vague. The backend may be arranged to query the occupier for more details. For example, if the occupier reports "my heating is not working" the inventory engine may query whether the system has power, whether there is hot water or whether any warning lights are illuminated. Even if the occupier provides a good description of the fault, it is still unlikely that the repair agent can determine exactly which parts will be required. Once the repair agent is at the job site and has diagnosed the problem, they can determine whether they have all of the necessary parts to effect a repair. If not, they can use their app to request the relevant parts from the inventory engine. The sequence of steps is then the same as for the low stock scenario described above. As an additional refinement, the inventory engine can determine that a problem Y often accompanies the problem X diagnosed by the repair agent. In this case, the engine will also determine how further parts to address problem Y can be supplied to the agent. Debrief from system and / or agent The survey engine is arranged, in response to a job being identified to the backend as completed, to identify the parts used from each of the vehicles that attended the job. The survey engine then performs a comparison between the parts actually used and the BoM for the job. It then updates the jobs database so that the BoM for similar installations and repairs will be more accurate in future. While the automated inventory system can identify unused parts, extra parts that were present on the agent's vehicle and dynamic re-stocking, it cannot identify parts that were not available but would have assisted the agent in some way. A debrief statement or completed form may also be obtained from each of the agents. The form could pose questions such as "Did you have all of the items that you needed?", "would you have been able to do a quicker, neater or cheaper job if you had further items to hand?" and so on. The survey engine is arranged to update the jobs database to include the further items identified in the debrief statement(s) from the agents. The survey engine may also provide information to further engines such as the scheduling engine. The survey engine may further determine the time required by each agent for a particular job, as well as the carbon emissions of the job. (Re)stocking vehicles Stocking and re-stocking vehicles is governed by two principles: Bring inventory levels of generic parts to a predetermined level, and Identify and load specific parts for upcoming installations and repairs The scheduling engine is arranged, in response to data from the jobs database and the vehicle stock database to identify the optimum level of generic parts to be stored on each vehicle. Agents traditionally feel more comfortable with a very generous inventory of all parts to ensure that they never run out. However, this has significant financial and environmental costs due to dead inventory being carried around in agent's vehicles. The scheduling engine is arranged to determine the optimal level of inventory for the generic parts by identifying the agent's next jobs and determining a probability of an agent running out of a particular part before returning to the warehouse. This probability determination can consider the following: The Bills of Materials (BoM) for the allocated jobs Previous requirements for extra parts for similar jobs, and The probability that an agent will be allocated to different jobs The scheduling engine then reduces the quantity of each item until an acceptable probability of running out is achieved, for example 0.05. Alternatively, the scheduling engine may forecast and measure the age of stock. The probability threshold is preferably varied in response to the location of the scheduled jobs. For example, if an agent has a job in a remote area, the probability threshold may be reduced to 0.02 to reflect the inconvenience and expense of running out of stock a long way from alternative sources. The inventory engine is arranged to populate a database with the stock level data to generate a record of historical stock level data for each vehicle. The inventory engine is further arranged to access a database of performed jobs for a particular vehicle. From the historical stock levels and the performed jobs, the inventory engine generates a reference file for the particular vehicle. A similar reference file is then generated for further vehicles. The inventory engine then uses machine learning to train an artificial neural network (ANN) to identify relationships between historical stock level data and performed jobs. The trained ANN can then respond to details of at least one scheduled job in respect of at least one vehicle to determine a minimum stock level for at least one of a plurality of items. A safety margin is preferably provided to reduce the probability of an agent running out of an item. The inventory engine is preferably arranged to derive the safety margin using carbon emissions calculated for the re-stocking of at least one item during the scheduled job and also using carbon emissions for carrying excess items. The inventory engine is preferably arranged to consider at least two scheduled jobs to determine the minimum stock levels. The inventory engine is preferably also arranged to generate the reference files in response to an item running out during a performed job. Job-specific stocking of van The scheduling engine is arranged to consider all the jobs to be performed in the next period of time, typically the next week. Existing scheduling techniques are used to determine which agents are going to attend which jobs. The scheduling engine will have access to the Bill of Materials (BoM) for each of those jobs (which may have been generated by the automated survey system described below). The BoM may conveniently be divided into those parts intended for the plumber, electrician and heat pump engineer. For each vehicle, the required parts will then be those specific to that agent from all of the BoMs scheduled for that agent. The scheduling engine will also have access to the vehicle parts database to determine what parts are already available to the agents and can subtract those from the combined BoMs. The optimal stock level as determined above may be added to the combined BoMs to determine the appropriate stock level in each vehicle. As stated, those vehicles destined for jobs in remote areas may also be allocated a higher minimum stock level since the consequences of running out of one or more parts is more severe. The list of components for each vehicle is then provided to warehouse staff and added to the vehicle. In a preferred embodiment of the present invention, the scheduling engine is arranged to divide the BoM for a particular job between generic and specific parts. Traditionally, a surveyor would generate a Bill of Materials (BoM) and warehouse personnel would load every item into a delivery vehicle or an agent's vehicle. For a heat pump installation, for example, the BoM will include hundreds of parts but a large number of these will be small parts such as elbows, olives, isolation valves and so on. Picking and loading such parts for each job generates a lot of work for the warehouse staff. It is much more efficient for the warehouse staff to load only the main items for a job such as a heatpump, mounting kit, control unit, radiators and so on. The agents then rely upon the generic stock in their vehicles to provide the remaining items such as pipe, elbows, valves, cable, switches etc. However, it has not been possible to date, to arrange for appropriate stocking of each agent's vehicle before a particular job or series of jobs. The scheduling engine is arranged as follows, for each vehicle: Identify all upcoming jobs for a particular timeframe (e.g. one week) Obtain the BoMs for those jobs Identify the relevant portion of the BoMs for the vehicle under consideration Group the parts for all of the BoMs into a combined list Communicate the list to warehouse staff (e.g. via an app on their devices) It will be apparent that this system saves significant effort at the warehouse. Rather than identify and pick a set of parts for each of several jobs, the warehouse staff only need to pick each part once per vehicle. For example, rather than picking 8 different quantities of 15mm elbows for 8 upcoming jobs, they only need to pick one (larger) quantity. Calibration during stocking Load cells are subject to drift over time, meaning that a weight reading from a load cell may change despite there being no change in the actual load on the cell. Load cells subject to a harsh environment, such as an agent's van, are more prone to such inaccuracy than those is a clean, static environment. Calibration of weighing apparatus in a warehouse is well known and usually entails two steps: establishing a tare value in which a parts container is emptied and the weighing apparatus reset establishing a load rate value in which a defined number of parts (or a reference weight) is added to the empty container to derive a function of load versus output Such steps are time consuming, which is especially inconvenient when they have to be conducted frequently. According to an embodiment of the invention, the inventory engine is arranged to perform an automatic calibration during the restock process. Imagine that warehouse personnel are restocking a van. Exemplary steps are as follows: Push real (1030, Figure 10) or virtual button to signal re-stock to inventory engine Obtain a weight reading from all load cells or other weight sensors in the vehicle Instruct warehouse staff to add or subtract specific number of items from the containers, e.g. "add three 18mm elbows to bin 5" Obtain a weight reading for the relevant container (e.g. bin 5) Update a portion of the vehicle parts database to calibrate the relevant load cells The inventory engine then has two sets of data for bin 5, an initial reading and a second reading for three more elbows. The inventory engine has access to a database containing the weight of 15mm elbows. The inventory engine may thus calculate the load rate by dividing the change in reading(s) from the sensor or sensors by the expected change in weight (i.e. weight of three elbows). The tare value may also be derived from extrapolation as follows. For example, the inventory engine has a record that there are nine 15mm elbows in bin 5. This comprises a first reading, having both a sensor output and a known weight of items. The inventory engine then instructs the addition of a further 20 elbows and derives a load rate as described above. The load rate may be in any suitable units but is assumed here to be of the form: Change in sensor output / weight of single item The load rate is then applied to a further calculation to determine the sensor or sensors output when there are zero items in the bin, for example by multiplying the load rate by nine and subtracting this from the first sensor reading. This infers the sensor output for an empty container or bin from the two readings. In a preferred embodiment, a third reading is taken before the load rate and / or tare are updated. This can be achieved by instructing personnel to add a desired quantity of items in two stages. For example, if 20 15mm elbows are to be added to a bin, instructing the personnel to add 10 elbows, instructing the controller in the vehicle to weigh the relevant bin, instructing the personnel to add another 10 elbows and then instructing the controller in the vehicle to weigh the relevant bin. This permits a more accurate calculation of the load rate and tare to be performed. Alternative processes are possible, for example asking the warehouse personnel a question via a user device such as "How many elbows have just been added?" Another alternative is to instruct personnel to remove items, rather than add them. As another alternative, the inventory engine may utilise information that items come in packs of known quantity. For example, 15mm elbows may be provided in packs of 20. The inventory engine is arranged to update the calibration of a weight sensing unit using the expected weight of twenty 15mm elbows. A more accurate determination of the tare of a container can be determined by instructing personnel to empty the container and instruct a reading to be performed. The calibration value for the tare is then simply the reading from the sensor or sensors. In another embodiment, the inventory engine is arranged to instruct the warehouse personnel to remove all of the items from a container or to remove a container from a storage location. The inventory engine then instructs the system to conduct a measurement which will comprise the tare calibration value. The personnel may then be instructed to replace the container and / or parts therein. Dynamic scheduling Jobs do not always go to plan &agents can finish a task earlier or later than predicted by the scheduling engine. In this case the scheduling engine may re-allocate agents to more-efficiently use their time. For example, the scheduling engine determines from inventory information that an agent A has completed their job. This could be determined from the inventory system detecting the return of tools and / or a portable parts storage unit to the agent's vehicle or the vehicle door opening and closing and so on. The scheduling engine also determines that an agent B is behind schedule due to not yet having picked appropriate parts for their job or not having returned a power tool to the vehicle. The backend may request an update from these agents via the agent app. Figure 18(a) shows a display enquiring whether agent A has actually finished (rather than just driving off for lunch, for example). Figure 18(b) shows a display enquiring whether agent B has been delayed. The display also includes an option for agent B to update their expected finish time, for example by pressing a plus button on the screen. The scheduling engine can then reschedule agent A to attend agent B's next job. In the case of multiple agents working within a given geographical area, a dynamic schedule is developed and updated accordingly. The impact on carbon emissions is preferably considered when the dynamic schedule is varied. In another scenario, the removal of a part from the agent's vehicle will indicate that the agent is finished, or very nearly so. The scheduling engine can then interpret this as a trigger to schedule the installation agent for the next part of the installation. For example, in a heat pump installation, a plumber removes a part to fit to the hot water cylinder which signals that the installation is ready to be wired. The scheduling engine is therefore arranged to dispatch an electrician to the premises. Security In certain embodiments, the inventory system described above may conveniently be used to improve the security of the agents' vehicles. In particular, if the inventory engine detects destocking of the vehicle outside of working hours it can infer that a theft is taking place. If the inventory system is provided with a location detector (e.g. GPS) for the vehicle it may also detect destocking when the vehicle is not at a job site. 1. The inventory engine receives a stock update from a vehicle that indicates destocking 2. The inventory engine determines if this occurred during working hours (e.g. 8am to 6pm Monday to Friday) 3. If the destocking occurs outside of these hours then the inventory engine will alert the agent via the agent app 4. The agent may confirm that all is well, for example they may be re-arranging stock within their vehicle or re-stocking a portable storage unit 5. If the agent confirms that a theft is occurring then the inventory engine will inform the police 6. If the agent does not reply then the inventory engine may inform a fleet management authority (which may attempt to call the agent and then may call the police) 7. The inventory engine will optionally include the location of the vehicle if the system includes a location detector and images of the perpetrator if the vehicle includes a camera As an alternative to determining that the destocking is occurring out of hours, the inventory engine may determine that a theft is likely based upon vehicle location. Figure 19 shows a user interface image for this aspect of the present invention. There are a number of benefits to this arrangement. Once a theft has occurred, a highly accurate insurance claim may be made. In addition, precise knowledge of stock items out in vehicles and an ability to respond quickly may allow a more competitive insurance premium to be negotiated. Automated Survey Generally speaking, a survey will be conducted prior to a job being performed, particularly an installation job. This permits the warehouse to identify and deliver the appropriate parts to the relevant premises and for scheduling the appropriate agents for the job. A survey may include consulting a map or an arial image of the premises to determine key parameters for the installation. This might include the roof area and orientation for a solar panel installation, the size of the premises and possible location of the fan unit for a heat pump installation or the proximity of car parking to a premises for fitting an electric car charger. Usually a surveyor will visit the premises to perform the survey, prior to the job being started. This is expensive in both financial and environmental terms. Since he or she has to travel between premises, the surveyor will be limited in the number of surveys that can be conducted and will need a salary and a vehicle. This also introduces delay until the installation can commence. With up to 70% of heat pump installations being "distressed installations" (that is to say the occupier's previous system has failed) this is a serious drawback. This aspect of the present invention is concerned with eliminating the requirement for a surveyor to visit the premises before a job can start. The occupant of the premises is provided with an app for their device. The occupant provides information, measurements and / or images of their premises which is interpreted by the survey engine. The survey engine then determines the necessary parts and, preferably, also scheduling of required agents. The survey engine comprises a machine learning engine, preferably an artificial neural network (ANN), which will require training. In a training phase, the survey engine accesses lists of parts actually required for previous installation jobs stored in the jobs database as well as at least some of the following parameters: Age of the property Size of the property Nature of the property (detached house, semi-detached, terraced house, flat etc.) Number of rooms Floorplan(s) of the property Volume of individual rooms Property construction (e.g. concrete floors / suspended floors, brick / timber) BoM as determined by the survey Time and scheduling on-site for each agent The survey engine is trained to determine the correlation between at least some of these parameters of a property and the parts actually used for the installation. It is preferably also trained to determine the likely time required by each trade to perform the installation. Alternatively, or in addition, training of the survey engine may be conducted using the correlation between the parameters of a property and the BoM generated by a surveyor. This will permit training of the survey engine on historical data collected before significant data is obtained from the automated inventory system. While this training data will not be as precise as that collected from the automated inventory system, it could provide a significant amount of training data at the outset. In use, the survey engine is provided with factual parameters about the property from the occupier and generates a list of the parts required for the proposed installation. This information is used to stock appropriate vehicles for the installation which then proceeds normally. After the installation, a feedback loop is implemented such that the survey engine is provided with the automatically-collected inventory data from all of the vehicles involved and compares this with the automatically generated BoM. Thus, the survey engine performs continual training to improve performance as further installations are performed. To perform the survey, information collected such as via an app or web portal is provided in conjunction with the survey engine. The occupant is preferably provided with an app on a device such as a mobile phone, the app having the capability to pose questions, measure distance and possibly to take photographs. Occupants, of course, may request a friend or relative to perform the steps for them. An exemplary set of steps for the occupant's app might be: 1. Occupant to confirm their address and the nature of the job 2. Occupant to provide the app with high level information such as the number of rooms, date of construction and so on. 3. Occupant to measure and photograph their outside space using the app 4. App (or survey engine) determines whether the inputs are sufficient and, if not, explains what the occupant is to do 5. Occupant to measure and photograph the interior of the premises 6. App (or survey engine) determines whether the inputs are sufficient and, if not, explains what the occupant is to do 7. App requests further information such as availability for further survey and conducting the job 8. If possible, the survey engine determines at least the BoM and preferably the scheduling of agents and the overall cost. 9. The survey engine, via the app, provides a quote or estimate to the occupier which the occupier can accept, reject or request contact from a customer service agent 10. If the occupier accepts the quote or estimate, a deposit may be taken and the job passed to other backend functions for parts ordering and agent scheduling 11. If the survey engine cannot determine the BoM etc. from the app data then it will schedule a visit from a surveyor. The surveyor can then be provided with a partially pre-populated survey form which may permit a faster survey to be conducted In any case, a surveyor may review the BoM generated by the survey engine, in addition to other information such as images of the property, to ensure that it is sensible before the parts are actually picked for the job. Whether to dispatch a surveyor may be decide by a survey engine using a trained artificial neural network. To train the network, the inventory engine arranged to generate one of a multiplicity of reference files from the stock level data and details of previous jobs. Each file comprises a set of parameters for one of a plurality of premises, each file further comprising details of a job performed at that premises and a list of items associated with that job. The survey engine is then arranged to train the artificial neural network based on the training data and the sets of parameters for each of the plurality of premises and the associated list of items. Once trained, the survey engine responds to a first plurality of parameters for a premises, to generate a first confidence level. This confidence level indicates the confidence that the survey engine can generate an accurate list of items for the job. If the first confidence level exceeds a first predetermined threshold, the survey engine proceeds to generate a list of items required for the installation of hardware at the job. However, if the first confidence level does not exceed the first predetermined threshold, then further details are requested. The survey engine communicates a further request to a resident via their device and receives responses to generate a second plurality of parameters. The survey engine then generates a second confidence level using the second plurality of parameters. The second confidence level indicates the confidence that the survey engine can generate an accurate list of items for the job. If the second confidence level exceeds a second predetermined threshold, the survey engine will generate the list of items required for installation of hardware. If the second threshold is not met, the survey engine will communicate a message that a surveyor is to be dispatched to the premises. In one embodiment, the measurement steps may be omitted and the survey engine arranged to operate solely on the photographic data. The occupier may be instructed to measure the length and width of each room. The occupier may also be instructed to measure ceiling height to permit the survey engine to calculate the volume of each room. Using machine vision techniques, the surveying engine will be able to estimate information such as: Size of the rooms Nature of the flooring Suitable size and location of radiators Suitable size and location of fan unit Length of pipework Length of wiring Installation time for radiators and fan unit The survey engine exploits the commonality between previous jobs (or at least previous surveys) and the proposed job. In most countries, many property types have been reproduced thousands or even millions of times so a high degree of accuracy can be obtained, even from modest information provided by the occupant. While a heat pump installation has been used in this example, the survey engine is equally suited to predicting other installations such as solar panels and electric car chargers.

Claims

l.An automatic inventory system for a vehicle licensed to be used on a public highway, the vehicle containing a store comprising a plurality of each of a plurality of items stored in containers,the inventory system arranged to measure stock level data for at least one container and wirelessly transmit the stock level data for the at least one container to an inventory engine, wherein at least a first type of item and a second type of item are located in the container,the inventory system further comprising an image capture device arranged to capture an image of each container and transmit the image to the inventory engine,the inventory engine being arranged, in response to stock level data and image data for a particular container, to determine the quantities of the first type of item and the second type of item located in the container.

2. An automatic inventory system as claimed claim 1, wherein the inventory system comprises at least one weighing device per container and the stock level data is weight data.

3. An automatic inventory system s claimed in claim 1 or claim 2, wherein the image capture device comprises at least one camera mounted to the vehicle.

4. An automatic inventory system s claimed in claim 1, claim 2 or claim 3, wherein the image capture device comprises at least two cameras mounted to the vehicle.

5. An automatic inventory system as claimed in any of claims 1 to 4, wherein the image capture device comprises at least one camera located on a user device.6.An automatic inventory system as claimed in claim 5, wherein the inventory engine is further arranged to instruct a user via a user device to capture at least one image of a container using the user device.

7. An automatic inventory system s claimed in claim 6, wherein the inventory engine is arranged to instruct the user to capture at least one image in response to at least one image capture device mounted to the vehicle being obscured.

8. An automatic inventory system as claimed in any one of claims 1 to 7, wherein the inventory engine is arranged to compare a plurality of items in the image data with a plurality of images stored in a database to identify which items comprise a first item and which items comprise a second item.

9. An automatic inventory system as claimed in claim 7, wherein the inventory engine is arranged to identify a rogue item having no matching image in the database.

Images