TABLE OF CONTENTS
- Audit Trail
- Command Execution
- Connector Box
- Data Point
- Device Driver
- Device Portfolio
- Device Type
- Electronic Lab Notebook (ELN)
- Execution View
- Laboperator API
- Laboratory Information Management System (LIMS)
- Parameter Page
- Role-based access control (RBAC)
- User Interface
- Webhook Subscriptions
- Workflow Event
- Workflow Field
- Workflow Run
- Workflow Step
- Workflow Step Template
- Workflow Template
To integrate third-party applications with the Laboperator ecosystem, Laboperator offers an extensive HTTP-based Application Programming Interface (API). More information can be found in the API folder.
A record of metadata about a file stored in the file storage of the Laboperator system. An Attachment always has a relationship to a container record. The container might be a Data Point, Workflow Field, or Custom Attribute. An attachment can be considered GxP raw data, when holding Device data in a file format.
Every change in Laboperator is tracked and time-stamped. The Audit Trail logs show therefore any activity made by users or the system itself.
You can use Laboperator Automations to automate behaviors globally and independently from a specific Workflow. Based on certain triggers (e.g. a Resource is opened) different actions can be executed (e.g. a Webhook is executed to update Workflow runs in a Collection).
A Channel represents a set of related Data Points of a Device. Example: A balance has a weight channel.
Collections are used to organize Resources in Laboperator e.g. Devices or Workflow Templates. The concept is similar to a folder system known in Windows or Mac. A Collection can thus also be seen as a folder.
A command that a Device interface accepts to allow remote control. The Device Type holds information about the Commands supported. The Device Driver implements logic to process Commands towards the Device interface.
A record of a Command sent to a Device, including the parameters of the Command and the Execution Status. The Status is changed to "send" when the Device executing the Command is online and the Command is recognised by the Device. This is checked in the API Application, which marks the time at which the Command is then forwarded to the Device.
The Command Execution Status is changed to "confirmed" when the Device Driver has received and processed the Command and has received confirmation from the Device that the Command has been processed. For Commands that result in an immediate response, this Status can be skipped.
The Command Execution Status is changed to "complete" when the Device Driver has received and processed the result of the Command.
The Command Execution status is changed to "fail", if the Device Driver has received an error message from the Device or cannot even process the Command.
The Laboperator Connector Box is a small embedded computer that serves as a gateway for Devices to the Labopertor system.
A Data Point (aka datum) represents a distinct unit of data that was created by a Device on a specific Channel. All Data Points have a value and the timestamp of their initial recording.
The timestamp uniquely identifies a Data Point on a given Channel. All Data Points on a channel form a time series representing the state of a Device over time. As any data sent by a Device is stored as a Data Point, they are considered the raw data that Laboperator stores. As such Data Points have a special role further detailed in Audit Trail. A Data Point is an entity in the Laboperator software system with a corresponding table in the database.
A Dashboard is the visual interface of Device channels. Every Device comes with a predefined set of channels. Dashboards can also consist of channels from multiple (different) devices. With dashboards, devices can be monitored and controlled.
An external resource of data that has some kind of interface that can be used to connect to Laboperator. In Laboperator the term refers to the digital representation of such a unique Resource in the software.
- Temperature sensor
- Control software of a complex analytical instrument providing results via an API
A Device Driver or Driver for short is encapsulating the code required to communicate with one or multiple Device Types. A Device Driver can be parameterized to adjust for different Device configurations. A Device Driver can be used by different Device Types, which allows Device Types using the same protocols and similar functionality to share the driver used to communicate with it.
The Laboperator Device Portfolio is a constantly updated list of Devices supported by the Laboperator. This means a corresponding Device Type and Device Driver is available. Devices in the Device Portfolio are available to all customers of Labforward. For more information, please contact firstname.lastname@example.org.
A Device Type is a representation of a specific Device model. The Device Type specifies the vendor, the model identifier, the Device Driver to be used (specific versions) as well as the default Driver configuration. It describes the channels, channel types, commands, and default layout templates for the device model. A Device is always an instance of a Device Type.
Electronic Lab Notebook (ELN)
An electronic lab notebook (also known as an electronic laboratory notebook, or ELN) is software designed to replace paper laboratory notebooks. Labforward offers an ELN product called Labfolder.
Lab notebooks in general are used by scientists, engineers, and technicians to document research, experiments, and procedures performed in a laboratory. A lab notebook is often maintained to be a legal document and may be used in a court of law as evidence. Similar to an inventor's notebook, the lab notebook is also often referred to in patent prosecution and intellectual property litigation.
Electronic lab notebooks offer many benefits to the user as well as organizations; they are easier to search upon, simplify data copying and backups, and support collaboration amongst many users. ELNs can have fine-grained access controls and can be more secure than their paper counterparts.
Laboperator allows the direct incorporation of data from instruments to our ELN, Labfolder, replacing the practice of printing out data to be stapled into a paper notebook.
The Execution View of a Workflow is the interface for the end-user to execute a Workflow Run based on a Workflow Template.
The Laboperator API is a RESTfull API enabling the communication and data transfer between Laboperator and third-party software. Requests against the API are authenticated via OAuth 2.0.
Laboratory Information Management System (LIMS)
A laboratory information management system (LIMS), sometimes referred to as a laboratory information system (LIS) or laboratory management system (LMS), is a software-based solution with features that support a modern laboratory's operations.
Key features include—but are not limited to—workflow and data tracking support, flexible architecture, and data exchange interfaces, which fully "support its use in regulated environments". The features and uses of a LIMS have evolved over the years from simple sample tracking to an enterprise resource planning tool that manages multiple aspects of laboratory informatics. The definition of a LIMS is somewhat controversial: LIMSs are dynamic because the laboratory's requirements are rapidly evolving and different labs often have different needs. Therefore, a working definition of a LIMS ultimately depends on the interpretation by the individuals or groups involved.
Historically the LIMS, LIS, and process development execution system (PDES) have all performed similar functions. The term "LIMS" has tended to refer to informatics systems targeted for environmental, research, or commercial analysis such as pharmaceutical or petrochemical work. "LIS" has tended to refer to laboratory informatics systems in the forensics and clinical markets, which often required special case management tools. "PDES" has generally applied to a wider scope, including, for example, virtual manufacturing techniques, while not necessarily integrating with laboratory equipment.
In recent times LIMS functionality has spread even farther beyond its original purpose of sample management. Assay data management, data mining, data analysis, and Electronic Lab integration have been added to many LIMS, enabling Notebook (ELN) the realization of translational medicine completely within a single software solution. Additionally, the distinction between LIMS and LIS has blurred, as many LIMS now also fully support comprehensive case-centric clinical data.
In our product suite, we offer the inventory management system, Labregister, to track and manage your materials and solvents.
A container specifying data of interest. By referencing one or more Channels and a Start- and End-Time the Measurement defines a subset of Data Points in the system. The referenced Channels can be from different Devices. A Measurement (unlike a Data Point) is created by a specific User creating a relationship between the User and the data. Additional metadata of a Measurement is an optional description that can be used to describe why the data is of interest.
You can use Laboperator to get notified in a pre-defined way, e.g. to constantly monitor Device channels and get a Notification when a specific event - a data point on a channel - occurs.
Open Authorization (OAuth) is an open standard for access delegation. It is used to allow users to access websites and applications without giving them a password.
Registered applications can request authorization for a user and ask for specific permissions. Once authorized by the user, these applications can interact with Laboperator in the name of that user within the given permission scopes. How to do this in Laboperator can be found in OAuth Applications.
Representation of an organizational unit in the real world. Represents a tenant in Laboperator when used in a multi-tenant installation. An Organization has one or more Users who are members of the organization. There is always at least one administrator of an Organization. The separation of Organization is strict in the sense that a User can never see or request (via API) data from two Organizations at once. He has to switch the Organization context before seeing or requesting data of another Organization.
The Parameter Page of a allows the parameterization Workflow of a Workflow Run which is predefined in the YML-file of the Workflow Template.
Any type of content within the personal or other Collections is referred to as a Resource. This includes for example Devices, Connectors, Dashboards, Workflow Templates, Measurements, or Audit Trail.
Role-based access control (RBAC)
Rights to use functionalities in Laboperator, e.g. adding a Collection, are specified in Laboperator as permissions. A set of permissions can be unified through the definition of roles. Read more about how to set up Roles and Permissions.
Once the respective Permissions for a Role are defined, the role needs to be associated with the relevant users and collections. To do this, a Group needs to be defined. Here, a User can be assigned to multiple Roles and with that rights in the respective Collections.
With Laboperator you can create Samples for example to be referenced in a Workflow. These Samples can be added, edited, archived, deleted, etc. as any other Resource in Laboperator.
Secrets are sensitive, encrypted information that can be used in other application features. For example, passwords stored as Secrets can be used by Webhook actions that require login credentials to fetch data from somewhere else. They can be implemented in a Workflow or Workflow Step Template and thus avoid the problem of having to re-enter the password for each new Webhook action.
Representation of a real person using the Laboperator system. A User can be a member of multiple Organizations. Technical or machine Users that do represent a real person should be avoided if possible.
The Laboperator User Interface refers to the web-based User Interface where the User can interact with the Laboperator Software. The User Interface can be visited on any device provided with a web browser such as PC, Laptop, or Tablet.
Webhooks enable the receiving of push notifications on specific events as a HTTP POST request to a pre-set URL.
The Workflow feature in Laboperator allows for highly flexible process modeling combined with powerful Automation that can make full use of the Device connectivity in Laboperator.
Represents a dynamic change of a Workflow Run such as adding, moving, or removing a planned Workflow Step.
A flexible container for data of all kinds similar to a variable in programming used in a Workflow. A Workflow Field is defined in a Workflow Template or a Workflow Step Template and is always created in the context of a Workflow Run. A flexible container for data of all kinds similar to a variable in programming used in a Workflow. A Workflow Field is defined in a Workflow Template or a Workflow Step Template and is always created in the context of a Workflow Run. Workflow Fields are a core concept of the Workflow feature used to model the complex and highly individual data structures in customer processes. Workflow Fields are stored as JSON in the Database. They support all primitive types defined by JSON Schema plus several custom types:
A numeric value with a specific unit.
A calculated field support basic logical and arithmetic operations.
MyQuantity * 2
A field referencing an uploaded file.
A reference to a resource in Laboperator.
A timer that can be controlled during the workflow.
An instance of a Workflow executed in Laboperator. It can be based on a Workflow Template or be populated dynamically with steps based on Workflow Step Templates.
Represents a single step instance in a Workflow Run. It is based on a Workflow Template or a Workflow Step Template and primarily holds the current state of its own execution. Once a Workflow Step has been started it can not be moved or removed. Planned workflow steps are not instantiated until they are actually started. The upcoming steps in a Workflow Run are solely based on the Workflow Template or Workflow Events.
Workflow Step Template
A Workflow Step Template is based on a YAML file following the Workflow Step Template schema. The proprietary schema is developed and maintained as part of the Laboperator product. It is a sub-schema of the Workflow Template schema.
A file-based description of a Workflow that can be executed in Laboperator. A Workflow Template is based on a YAML file following the workflow template schema. The proprietary schema is developed and maintained as part of the Laboperator product.
Was this article helpful?
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
We appreciate your effort and will try to fix the article