Field to Cloud Standards
Version R2024.1 Pre-Release Draft
Conventions
Key Words
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” below are to be interpreted as described in RFC 2119.
Versioning
The Trimble Field to Cloud Standard is a living standard with named releases. Named releases follow a modified calendar versioning scheme of the form RYYYY.N where:
YYYYis the full year of the releaseNis an incremental release number
Example:
R2024.1 represents the first standard release of 2024.
Policy Status
- ✅ Policy has been voted reviewed and approved by the standard community.
- ❓ Policy has been proposed and is pending approval.
Definitions
“A Trimble-Enabled Device”
Any discrete Trimble-owned or third party hardware that, through its integration with Trimble-owned software IP, supports workflows of value to Trimble customers.
Examples of Trimble-Enabled Devices
- An Android tablet running Trimble Transportation’s Driver Management Product: Instinct
- A gateway, connected directly to an ECU on a Class 8 vehicle, communicating with the CAN bus and interfacing through Trimble Cloud IoT
- A Trimble RTS573 sharing data with Trimble Connect via Trimble FieldLink
- A Trimble-branded, but Bosch-supplied LiDar module publishing data to Project Seurat
- A Trimble machine control system, such as Earthworks, RoadWorks, GroundWorks or Siteworks via cloud and/or IoT systems.
- A Trimble in-field survey system (Siteworks, UTS etc) that may connect to backend systems via IoT, or other in-field systems via mesh, cloud, or similar point to point or peer to peer comms.
- Telematics devices (headless) that support AEMP/ISO 15143-3 (or custom) style telematics data streams to back end systems like WorksIQ.
- Aurora (third party hardware IP) with T4D Edge (Trimble software IP)
Non-Examples of Trimble-Enabled Devices
- A Trimble-developed hardware module sold to another company with no connectivity to Trimble products or services
- Trimble software IP that is sold to run on a device that is not in any way connected to Trimble’s systems, nor is in any way associated to a recurring revenue stream for Trimble.
- An Android or iOS smartphone running Trimble Installation Manager (used to option & license Trimble GNSS & Optical devices)
“A Trimble Device”
A Trimble-Enabled Device that, through its use of transport layer security, can authenticate itself with Trimble Identity.
Examples of Trimble Devices
-
Aurora (third party hardware IP) with T4D Edge (Trimble software IP)
-
Any Trimble-Enabled Device requiring:
- Connectivity with Trimble IoT
- Device-assigned licenses from Entitlement
- Over-the-air updates
Non-Examples of Trimble Devices
- A foreman’s personal Android tablet running the ProjectSight mobile app.
- A desktop computer running Trimble Business Center.
The Trimble Device Lifecycle
The Trimble Device Lifecycle consists of four key lifecycle phases:
- Pre-Release
- Release
- Maintenance
- End-of-Connectivity
We also identify a “Cross-Over” Phase, categorizing policies that apply across multiple lifecycle phases.
Pre-Release Phase
Constraints
- Active device design, development, and procurement
- NO sales
Policies
✅ Every Trimble-Enabled Device SHOULD streamline its software integration footprint through use of shared libraries (e.g., Bedrock, “Side Car” agent, as appropriate for the use case).
-
Trimble wastes significant capital expenditure having every team write software integrations by hand, from scratch. We improve security, integration, and time to market by writing common software modules once, and applying them consistently.
-
Promotion, visibility and access to these common libraries must be prioritized.
-
Execution Activity: Outside of Bedrock, there is no single “sidecar” agent that exists today.
✅ Every Trimble-Enabled Device with a user interface that carries the Trimble brand MUST follow the UX guidelines set by the Trimble UX Board.
- Customers that use Trimble products increasingly expect a consistent user experience.
✅ Every Trimble Device MUST use a tamper-proof secure hardware element for storage of confidential and cryptographic data (e.g. keys, credentials, and personal information).
- Device identity cannot be assured without being able to ensure that cryptographic secrets are securely stored.
❓Every Trimble Device MUST rotate device certificates in compliance with Trimble’s cybersecurity policy
- At the time of writing, the rotation frequency is every three years. The history of legacy devices unable to meet the changing cybersecurity landscape has introduced risk Trimble cannot afford to continue.
❓Every Trimble Device MUST use the common Platform API for the registration and rotation of operational certificates (currently, the Bootstrap Service).
- Approval pending on-site workshop June 2024.
✅ Every Trimble Device MUST support firmware updates on any firmware responsible for connectivity with Trimble.
❓Devices SHOULD support over-the-air (OTA) firmware updates. Where not possible, devices MUST support local firmware updates through appropriate mechanisms.
- Approval pending on-site workshop June 2024.
❓Every Trimble Device SHOULD use components that have been validated by at least one Trimble development team and entered into a common “Trimble Certified” Hardware Component database.
- This component database does not exist in a complete form today, but it’s been a known and identified gap we have an opportunity to close.
Release
Constraints
- New sales
- Software and security patches
- Troubleshooting and support
- Connectivity with Trimble
Policies
✅ Every Trimble Device MUST at all times be under the ownership and control of at least one Account.
- Accounts MUST be the root container for Identities, including Devices.
- Accounts MAY be provisioned for customers, resellers, and Trimble businesses alike, allowing a Device to be owned by multiple Accounts over time.
✅ Every Trimble Device SHOULD be assigned licenses for Trimble products or capabilities through Trimble’s centralized entitlement management system, and devices’ licenses for Trimble products or capabilities SHOULD be determined from EMS data.
- The management of licenses and entitlements will be managed pursuant to all applicable Trimble policies related to EMS, DX, and related systems.
- At the time of writing, the centralized entitlement management system for Trimble is EMSv4. EMSv4 supports device-based licensing natively.
✅ Every Trimble Device MUST be provisioned, directly or through integration, with the central Trimble Device Management System.
- Trimble MUST have global visibility of deployed devices to effectively be able to integrate them with adjacent services.
- Provisioning MUST handle all necessary orchestration, including set up of the device identity, certificate management (registration, rotation, and revocation), and account membership.
❓Every Trimble Device MUST regularly submit its firmware for vulnerability scanning. Vulnerabilities MUST be remediated according to the Trimble Secure Development Life Cycle (TSDLC).
Maintenance
Constraints
- NO new sales
- Software and security patches
- Troubleshooting and support
- Connectivity with Trimble
End-of-Connectivity
Constraints
- NO new sales
- NO Software and security patches
- NO Troubleshooting and support
- NO connectivity with Trimble
- Examples of connectivity with Trimble include:
- Platform Services: TID, IoT gateway, Entitlements
- Businesses Services: Civil WorksManager/WorksOS, Transportation Unified Log Service
- Examples of connectivity with Trimble include:
Policies
✅ Every TrimbleDevice that cannot conform to the standards herein MUST reach end-of-connectivity no later than January 1, 2030.
- A robust end-of-life policy for non-conforming Trimble Devices is required for Trimble’s Field to Cloud Strategy to scale.
- A 2030 cutoff corresponds for many businesses to approximately 1.5 hardware release cycles, providing sufficient time to adopt the standard.