An interlocking system forms a vital part of a railway signaling system because it ensures the safe movement of trains. For one by controlling movable track elements like switches and for an-other by controlling signals. The engineering design of interlocking systems poses challenges to both engineers at e.g. Siemens and the infrastructure manager, e.g. Prorail in the Netherlands. Challenges arise from the cumber-some, labor intensive, conservative, ambiguous and failsafe nature of the interlocking engineering design processes. Best practices in lean production systems raise Siemens’ interest in a lean engineering approach, i.e. reduce the ‘waste’ that does not contribute value to the final rail product. The development of RailML, an open source IT tool that aims to standardize the ex-change of data in a variety of rail processes, may prove the lean catalyst. The lean philosophy has however seldom been applied in engineering design processes. Therefore, this research aims to provide insight in the drivers of the engineering design chain that decrease development time, increase data reliability and make application more flexible, while ensuring (fail-)safe systems. For that purpose, this thesis investigates the next research question: To which extent can RailML potentially enable a leaner engineering design of rail interlocking systems? This study focuses on the Dutch railway network. Furthermore, this study only considers engineering design processes and RailML as the data exchange tool. Five sub research questions lead to an answer: Which methodology leads to a lean transformation of rail interlocking systems’ engineering design? Best practices about lean transformations lead to a methodology that commences with defining complexity into standardized and varying requirements of the final design. A future lean structure of the chain follows from mitigating ‘waste’ and achieving lean transformation directions. The more standardized the require-ments, the higher the potential for an IT tool like RailML to miti-gate ‘waste’. Case specific transformation directions include ‘waste’ prioritization, process standardization, open source IT tools, a modular process and information sharing. A model study allows to quantify the improvement of a strategy like RailML on the status quo and benchmark the lean effect. Four criteria count: costs, time, interdependencies and ambiguities. How would a future lean interlocking engineering design change the status quo? The status quo contains twenty processes that struggle with non value added work in progress, many (non machine readable) data transfers, ambiguous interlocking design from scratch, high fixed costs, many validation processes and low productivity rates. A lean engineering design process mitigates most of that ‘waste’ by concentrating on five main processes: project definition, data preparation, interlocking area design, interlocking engineering and a dry test. Realistically, varying requirements and completely new interlocking areas prevent full automation of the engineering design chain. How should interlocking be implemented into RailML for the purposes desired by Prorail? Prorail proposed to use and provided the files of the Santpoort Noord interlocking area as a case study to formalize the interlock-ing in RailML. A RailML interlocking formalization from the per-spective of a train requesting a route, results in a complete, con-cise and RailML group coherent interlocking formalization that allows to capture all necessary rail elements for (Siemens’) inter-locking engineering and the two-block three-aspect system ATB-EG. The RailML structure contains two main sub elements: signals and segments. The signal element captures aspect dependencies on the basis of entrance speed profiles, signal aspect and target signal combinations. The segments element covers route relevant elements. In the case of ETCS level 3, the interlocking formaliza-tion might ultimately become superfluous. How does RailML change the interlocking engineering design chain when implemented as the rail data exchange tool for railway signaling systems in the Netherlands? RailML mainly improves the design stage by machine readable transfers, elimination of interlocking area design from scratch and automates test protocol development. At the engineering stage, RailML eliminates the data preparation process and a part of interlocking IT engineering. These improvements do however assume the existence of a single data source in the chain e.g. a GIS. RailML mainly lacks the ability to achieve a modular engi-neering design, continuous process flow, improved project man-agement and lean perfectionism / learning effect. What benefits does the application of the RailML formaliza-tion have during the engineering design of an interlocking area over the traditional and lean process structure? RailML reduces Siemens’ costs between 17%-27% and covers 21%-35% of a lean cost reduction, depending on project complexity. RailML improves productivity by 26%-47% although this only covers 6%-14% of a lean improvement. RailML relatively improves transaction costs but needs a larger average of non value added work-in-progress to achieve so. RailML reduces the tier rejection rate by 47%-77%, which is 50%-81% lean. RailML worsens the non value added work-in-progress for high complexity projects. RailML shows deviating lead time performance: a reduction of 2%-25% which is 2%-64% lean. RailML reduces the current amount of design rules by 55%, which is 85% lean. In general, RailML improves the performance of the interlocking engineering design chain on almost every performance metric, for each project complexity. RailML covers about 43% of the lean state for a medium complexity interlocking area as Santpoort Noord. Academically, the proposed interlocking formalization excels in its way of incorporating signal aspect dependencies, minimal amount of data (barely any redundancy) and alignment with both industry and infrastructure managers. In fact, on the RailML congress of September 2013, the RailML group decided to study the implementation of the developed formalization for different signaling systems than the Dutch and different engi-neering processes than Siemens’. The lean methodology leads to a scientific benchmark of a strategy’s, e.g. RailML’s, lean perfor-mance. The methodology however needs a substantial amount of data and does not seem to work as well for high complexity pro-jects as simpler ones. The author mainly recommends Siemens and Prorail to continue with the development of RailML, to start an interlocking engineer-ing design pilot project with RailML and to enlarge the degree in which interlocking areas can be standardized. From an academic standpoint, the author mainly recommends to study whether the interlocking formalization works for different signaling systems, infrastructure managers and interlocking engineers, to quantify the effects on the safety case, to investi-gate effects of more detailed data, to find design modeling tech-niques that work on a micro level and to test the hypothesis that high complexity engineering design projects suit less for a lean transformation.