Process Types represent the types of jobs and business processes relating to assets modeled by the system. A job can be performed on an asset: a vehicle can be repaired or inspected; it can be performed by an asset: a tomato harvester can harvest a field or a vehicle can take a trip; or, a job can be performed using an asset: a part can be placed into a vehicle. Each of these can be represented as a Process in the system: an instance of a "Repair", a "Trip", etc., and each provides information about what a resource does, instead of simply about the state of that resource.
Processes also serve as containers for one or multiple types of activities, and so help to make sense of activities and make them reportable. For example, a monitored vehicle could send messages to the system every time its engine turns on or off, and can send a GPS reading every few seconds. Activities based on these messages can be helpful on their own, but they are truly given meaning when grouped into one process: a "Trip" process, which starts when the engine is turned on, stops when it is turned off, and contains all the information about where that vehicle went during the duration. Once these activities are bundled into a process, the process can be compared against other processes, and can store statistics about that business process. In the above example, a process could maintain a running statistic of the distance traveled, the average elevation of the vehicle, or the peak engine temperature during the journey.
Each process type has two required fields that define the duration of the process: Start Time andEnd Time. Beyond that, a user may define any number of fields for a process type and may divide them into sections. A process may also belong to one or several types of resources, and the allowable resource types to which it may belong are defined in the process type. If a process does have a parent resource, it will contain a reference to that parent. Along these lines, a parent process contains no direct references to its many constituent activities, but each of these activities contains a reference to the process.
Like a resource or group type, a process type must also have Key and Label fields, which serve as a unique identifier and common name for instances of the process type, respectively. A user can flag a single field as the Key and/or Label (except the Start Time and End Time fields), or can use Expression Language to combine multiple fields into a more complex string. The Key must be based off of a unique and required field, whereas the Label must only be based off of a required field.
Processes are started and stopped by the central processing engine based on the Routines that a user defines in the system. In the "Trip" example above, the system could create a new process and mark the start time every time it receives a "Engine Started" message from a monitored vehicle. Then, every time it receives a GPS reading, if checks if there is an open (started, but not finished) Trip for that vehicle, and then creates an activity for the GPS reading and assigns it to that trip. When it receives an "Engine Stopped", it marks the stop time for the current Trip.
As another example, a machine could send data about its power usage whenever it is on, but does not explicitly tell the system when it has begun or completed a job. So, whenever the system receives a power reading, it can search for a started "Job" process; if one does not exist, it can start a new one, but if one does exist, it can check a user-defined "Last Update" field to see when the Job last received a reading. If a machine sends a reading every 5 seconds while it is running, but the last time the system received a reading was an hour ago, then the system knows that a new job has begun; it can set the stop time of the previous Job to the last time it was updated, and create a new Job beginning with the reading it has just received.
Processes can be created in response to more than just device messages, however. A "Repair" process could document the entire process of repairing an asset. Whenever a user notices that an asset is broken, they could log into the system and submit a form titled "Log Problem" with the ID of the broken asset. The system, upon receiving the submission of such a form, could start a new Repair process. An engineer could then submit forms whenever he or she starts the repair, or requires a new part to fix the asset, and all this information would be logged in the process. The system would mark the completion time of the process whenever it receives a "Repair Completed" form submission for that asset ID.