Machine Learning (ML) based prognostics and health monitoring (PHM) tools provide new opportunities for manufacturers to operate and maintain their equipment in a risk-optimized manner and utilize it more sustainably along its lifecycle. Yet, in most industrial settings, data is often limited in quantity, and its quality can be inconsistent - both critical for developing and operating reliable ML models. To bridge this gap in practice, successfully industrialized PHM tools rely on the introduction of domain expertise as a prior, to enable sufficiently accurate predictions, while enhancing their interpretability. Thus, a key challenge while developing data-driven PHM tools involves translating the experience and process knowledge of maintenance personnel, development, and service engineers into a data structure. This structure must not only capture the diversity and variability of the expertise but also render this knowledge accessible for various data-driven algorithms. This results in data models that are heavily tailored towards a specific application and the failure modes the development team aims to detect or predict. The lack of a standardized approach limits developments' extensibility to new failure modes, their transferability to new applications, and it inhibits the utilization of standard data management and MLOps tools, increasing the burden on the development team. DeepFMEA draws inspiration from the Failure Mode and Effects Analysis (FMEA) in its structured approach to the analysis of any technical system and the resulting standardized data model, while considering aspects that are crucial to capturing process and maintenance expertise in a way that is both intuitive to domain experts and the resulting information can be introduced as priors to ML algorithms.

DSM is known for its simplicity and conciseness in representation and exists in the form of a square matrix that maps the relationships between the set of system elements [Yassine and Braha 2003; Browning 2015]. An example DSM (= 4) is shown in Figure 1. Based on the DSM convention described by Browning [2001], Element 1 depends on Element 2 as indicated by a red cell entry in row 2 column 1 of the DSM. Likewise, Element 4 depends on Element 3 as indicated in row 3 column 4. The diagonal of the DSM maps each element to itself and is indicated as black cells in Figure 1. The diagonal is usually left empty but is sometimes used as a space to store element-specific data, such as the likelihood of changing the given element based on market projection [Koh et al. 2013]. The DSM in Figure 1 is not symmetrical across the diagonal, indicating asymmetrical dependencies between the system elements. For example, Element 1 depends on Element 2 but Element 2 does not depend on Element 1. In contrast, the example DSM shows that Element 2 and Element 4 have a symmetrical interdependency. It is important to note that a transposed version of the DSM convention is also widely adopted by many (e.g.

On December 10, 2019, Phillip Goter and Joseph Herriges hosted the webinar "Autonomous Vehicles: Technical Advancements and Legal Considerations." If you were not able to attend the webinar, you can find a partial summary of its contents in the Q&A below. Transportation system elements in this context include other vehicles, pedestrians, and cyclists, as well as the vehicle's environment, such as roadway infrastructure, buildings, signs, pavement markings, and weather conditions. The safe operation of an AV requires connectivity between the vehicle and other elements of the transportation system. AVs are enabled by artificial intelligence systems and connectivity.