specs/overview/S_DATA

Data Management

Tulip uses one server configuration per instance. So, if a company uses one instance per manufacturing plant, then there will be one server configuration for each manufacturing plant.

Tulip supports a variety of server configurations, including cloud-based, within a VM and on-premises.

Infrastructure

Tulip App Servers: Kubernetes + Kubernetes handles scale-out of application servers and services to thousands of nodes. Used in production by Box, SAP, New York Times, eBay, Comcast, IBM, and more.

Databases

The Tulip backend uses three major technologies for persisting data:

  1. Read Only Process Completion Data: PostgreSQL

    • Postgres scales to tens of terabytes of data. Our read-heavy analytics workload supports scale-out via read replicas.
  2. Digital Factory digital data (users, stations, apps, etc): Mongo DB

    • MongoDB scales to terabytes of data and billions of documents. Per-customer databases allows for easy sharding to distribute load and scale out the cluster.
  3. Machine Outputs: Amazon S3

Data Integrity Control

Data inside the database is not changeable unless via the authorised controls inside the Tulip system. There are four main components to ensure application security:

SSL

  • 2048-bit RSA key
  • SHA384 signature
  • Yearly rotation
  • Forward-secrecy (ECDHE) preferred
  • Outdated cipher suites (SSL 2/3) forbidden
  • Qualsys SSLLabs A+ score

Database Security

  • Randomly-generated authentication keys
  • Colocated in AWS, only local traffic
  • Dedicated read-only accounts for analytics
  • Parameterization to avoid injection
  • Encryption-at-rest and encryption-in-transit

Web Security Standards

  • HSTS to prevent SSL-stripping MITM attacks
  • DOM Templating and CSP to prevent XSS
  • LocalStorage instead of cookies
  • X-Frame-Options to prevent clickjacking

Application Security

  • All web server endpoints verify ACL
  • Enforced with static analysis and code review
  • Password hashing: SHA512 client-side
  • Password hashing: bcrypt + per-user salt server-side
  • Password entropy estimation and minimums
  • Long, random keys for cells and tablets
  • Automated security updates
  • All production code reviewed by multiple engineers

System Data Creation and Management

Data is created and controlled in the following ways:

Data ElementCreated In/byStored InControls
User DataTulip EditorMongo1. Access controlled (authorised users)
2. System controls changes by design
Apps (inc. history and groups)Tulip EditorMongo1. Access controlled (authorised users)
2. Permissions
3. System controls versions
App VariablesTulip EditorMongo1. Variables are defined and stored in mongo, and utilized in the execution data saved in postgres
2. Each variable has a unique identifier, which cannot be changed
3. Records in Postgres are read-only values attached to that variable identifier
Stations (inc groups)Tulip EditorMongoAccess controlled (authorised users)
MachinesTulip EditorMongoAccess controlled (authorised users)
Activity LogTulip EditorMongo
System Date & TimeServerAzureCannot be changed in the Editor or Player. Can be determined by a company's local time server. Takes into account leap years and daylight savings via custom server configuration for each instance.
System & Station TimezoneTulip EditorMongoAccess controlled (authorised users)
App Executions
Tulip Player continually updates the execution data locally, and on the server using Mongo DB’s underlying technology for updating collections across client and server. In the Tulip code this module is called the “state manager”. When a ‘process completion’ event is sent from the player to the server, it writes the current status of ‘state manager’ into a new row in the postgres db.
Postgres1. Access controlled (authorised users)
2. System controls changes by design
3. Read-only DB
4. Every method on the back end does an ACL check to make sure the logged in user has the appropriate credentials.
Tulip Table DataTulip Tables Page, Player, APIPostgresAccess controlled (authorised users)

Requirements

IDRequirement
39Support daylight saving time bi-annual hour changes
40Support leap years date adjustment automatically
801All records, including audit trail shall be Legible, ie. shall be human readable throughout the retention period.
804All records shall be Complete. Records shall include all data related to activity with no deletion or overwriting.
806All records shall be Enduring, ie. store, managed and unalterable for the full retention period.
807All records shall be Available and can be accessed for review, audit or inspection over the lifetime of the record (retention period).
811All records, electronic signatures, and audit trails must be protected to ensure they are readily retrievable throughout a pre-configured retention period.