HWDB Conceptual Overview

Stephen White

May 2022

Hardware DB, A Bit of History

• HWDB was originally developed and created for NOvA about 2008-ish.00
• By Dennis Box, Margherita Vittone and me. With guidance from Jon Paley


• It was created to track a specific set of parts for NOvA and some tests done on them.


• About 2015 it started being adopted by other experiments including:
• Mu2e, Icarus, SBND, Proto Dune, Ash River (currently under development)


• Known Issues with HWDB
• Supporting a new experiment means creating a new schema from scratch.
• Adding a new type of part/test requires developing and adding a new, distinct table or columns to the schema.
• Good at tracking current state but little to no historical data was kept.
• Very limited API allowing uploading data only.
• Utilizes original, very early, web technology which will not last for the life of DUNE.

DUNE Expands the Requirements

• The full current state as well as past history must be available for each item.
• Requires the complete test history for every item, not just the last one done on item or a history on a few items.
• Robust html access for queries, inserts and updates.

• Ability to see what an item is connected to or what is plugged into it.
• Both current and past history of all connections.
• Support for storage of associated documentation and or photographs.
• Create a unique physical identifier (PID) for every item as well as provide for the generation of their labels, i.e. bar codes.

• For a complete list of requirements: https://docs.dunescience.org/cgi-bin/sso/ShowDocument?docid=23333.

DUNE requires a very large set of discrete types of items to be tracked making creating individual tables for each item extremely difficult. Well, impossible.

Hardware Database for DUNE

• Hardware Database supports the complete life cycle of each item in the DB for the experiment as a whole.
• Manufacturing / Procurement
• Manufacturer created a component
• Where it was created
• You describe what items is to be stored in the DB, the data to be stored for it. As well as what items are allowed to be attached to it.
• No longer need a developer to add a table for each new type of item.
• You create a definition of what that item is, a pattern if you will.
• Item data is entered according to the pattern.

Hardware Database for DUNE

• Versioning is fully supported with a history of all changes.
• Displays the item according to the version in effect at the item’s creation or last update.
• The entire history of “patterns” and each item is available.
• Testing and Quality Control
• Create any number of tests for each type of item
• Run any test and store its data multiple times.
• There is no limit.
• View the entire test history.
• Support for Documentation, Photographs, URLS. – Can be tied to the Patterns, Items and Tests.
• A complete, secure, REST API is available for most of what the forms do.

Accessing the System

• The page the production link is on: https://dbweb0.fnal.gov/ - You can also access the development system
• All DUNE analysis experimenters have read only access.
• Requires a FNAL services account
• If you do not do analysis, you may need to be manually added.
• Login using your Fermilab Services account/password.
• We support the lab’s Single Sign On (SSO).
• Non-FNAL accounts are not allowed.
• Security is provided by
• Creating a role for one or more component types
• Adding users to roles.
• Data can be entered through web forms or a REST API.
• The API requires a CILogin certificate for security.

The Big Three

This system is built around the concept of

• Component Types
• Items
• PartIDs.
• This is integral to all web forms, APIs and database tables.

Component Type

• Component Type is simply a PATTERN, where you define what DATA will be collected for a type of item.
• This is a virtual construct.
• It is used to display a web form for specific to that type of item. It is also used by the APIs.

Name and PartIDs

An item is simply a physical piece of real world equipment.

Every Item must be barcoded with a PartID.

A PartID is a unique identifier defined according to DUNE specifications. https://edms.cern.ch/document/2505353/3

Every item must have a PartID attached via a barcoded label.

Moving Forward...

Jim Stewart will be giving an introductions to the Parts Identifier.

Hajime Muramatsu will provide training on setting up Component Type definitions.

Experience has shown that the success of the Hardware Database always depends on the willingness of the physicists to enter the data. Once a physicist leaves the experiment all unentered historical data is lost forever.