Jupyter notebooks have become central in data science, integrating code, text and output in a flexible environment. With the rise of machine learning (ML), notebooks are increasingly used for prototyping and data analysis. However, due to their dependence on complex ML libraries and the flexible notebook semantics that allow cells to be run in any order, notebooks are susceptible to software bugs that may lead to program crashes. This paper presents a comprehensive empirical study focusing on crashes in publicly available Python ML notebooks. We collect 64,031 notebooks containing 92,542 crashes from GitHub and Kaggle, and manually analyze a sample of 746 crashes across various aspects, including crash types and root causes. Our analysis identifies unique ML-specific crash types, such as tensor shape mismatches and dataset value errors that violate API constraints. Additionally, we highlight unique root causes tied to notebook semantics, including out-of-order execution and residual errors from previous cells, which have been largely overlooked in prior research. Furthermore, we identify the most error-prone ML libraries, and analyze crash distribution across ML pipeline stages. We find that over 40% of crashes stem from API misuse and notebook-specific issues. Crashes frequently occur when using ML libraries like TensorFlow/Keras and Torch. Additionally, over 70% of the crashes occur during data preparation, model training, and evaluation or prediction stages of the ML pipeline, while data visualization errors tend to be unique to ML notebooks.

Avionics control systems are typical real time systems-automatic control algorithms are realized as periodic computations where strict requirements on the timing can be derived by a control analysis. The requirements are effectively end to end timing requirements on the computation-from sensory input to actuator output-and have to be transformed into a detailed control software design. This analysis, together with a resource and performance analysis, is required early in the development process-neither hardware nor prototypes of the software can be assumed to exist-in order to estimate the cost of development and the cost of hardware to meet customer requirements. The paper investigates the applicability of a method (the period calibration method) to transform the end to end requirements of an avionics control software, into a design consisting of a set of periodic tasks with buffered data flows. The experience is discussed and shortcomings of the method are analysed.