This page summarises the specifications contained in the AEC Deltas project standards.

Summary

• Software Specification
  • Delta Container Specification (WP3)
  • REST API Specification (WP4)
  • Server Architecture (WP5)
    • Other notes:
      • Data Schemas/Standards
    • Links:
• Test Cases Specification

Software Specification

A detailed software description which can serve as a basis for a design or implementation.

As a knowledge provider partner, UCL puts forward the following that can serve as a base/prior work for the future development of the user requirements above & those mentioned in the grant work packages. The below are not "user requirements" per se, but more "technical requirements/background" based on the speckle platform which was previously developed as part of UCL within an H2020 grant.

Delta Container Specification (WP3)

• Authorship: the speckle server implements a discretionary access control layer that assigns an owner to each created resource (object, object collection, etc.). This is implemented via the speckle's api authentication mechanism.
• Encryption (SSL) is usually handled by the proxy server using standard letsencrypt certificates (and is not part of the implementation)
• Encryption at rest is usually handled by the database (mongodb) deployment (and is not part of the implementation). See the following documentation.

More information can be found in the dedicated page: https://github.com/aecdeltas/aec-deltas-spec/wiki/Delta-Container-Specification.

REST API Specification (WP4)

Speckle already has an api contract written in OpenApi v3, coupled with generated documentation of the endpoints.

• CRUD definitions:
• Objects can be found here
• Streams (object collections) can be found here

Delta updates and diffing is currently managed at the client level and operate on the object collection rather than individual objects. These can be enhanced to contain more granular update notifications about single/multiple delta updates.

Nevertheless, it is important to note that various client (CAD software) implementations will require different types of diffing to occur based, hence we recommend not implementing these behaviours server-side beyond a common-sense approach.

Server Architecture (WP5)

Publisher-subscriber design:

• The speckle server exposes both the REST API mentioned above, as well as a WS server
• All clients connect as either publishers or subscribers to the WS server on a resource-based classification, given permission access levels.
• The server propagates messages to all subscribers, but is also able to handle individual client-to-client messages.

Distributed architecture: The speckle server is stateless - all api calls are authenticated and WS messages are coordinated across all server instances.

Other notes:

Data Schemas/Standards

• Speckle is schema agnostic, supporting out of the box several object models developed internally by various companies.
• Furthermore, there is a planned integration with the BHoM object model.

Links:

• Speckle Server
• Speckle Api Specifications
• Speckle Client Integrations:
  • Rhino & Grasshopper
  • Dynamo
  • Revit, Unity, GSA, and others are WIP

Test Cases Specification

As identified in the User Story definitions above, the AECDelta specifications will need to be designed to be compatible, support or facilitate a wide range of data sets, model formats and types of information.

As a high level specification - data types ranging from schema-less raw data, through well defined proprietary formats, to API exposed object models - are required.

Depending on the data type. The scale at which a meaningful Delta/Change can, or is appropriate to, be detected will vary. For instance

• Unstructured - file or entire stream level deltas may be possible
• Structured - object level deltas may be possible

List of potential data sets and test cases:

1. Raw data, e.g. csv, .txt , unstructured primative data
2. Custom schemas, JSON
3. Geometry formats
4. IFC
5. Analysis model representations (e.g. Structural FEM, CFD model, Thermal Environmental models)
6. Multidisciplinary BIM models - building scale
7. Multidisciplinary GIS models - infrastructure scale
8. Fabrication model representation

A deliberate (and possible separate) consideration will need to be made for "large" data sets. Test sets to consider:

I. Point Cloud from laser scan
II. Bulk simulation results