Yes, the idea is to turn the layout into a self-sufficient world governed by rules controlled by software. However, a typical switch board would be presented showing the activity and permitting a user to set new routes and take over. Lastly, one would be able to control engines directly with the software acting to prevent collisions. JMRI documentation covers different types of block management to achieve these goals. If you have ever worked with databases, they remind me of concurrency models governing relational data.
1) Pessimistic Concurrency: A route is selected by a train and it is locked. All tracks are locked by that train until it reaches its destination. All other trains wanting to traverse a part of the route must go around it or wait.
2) Optimistic Concurrency: A route is selected by a train and not locked. As it approaches blocks, it requests access. If it is first to do so or if it has priority set (like passenger vs freight), access is granted and it proceeds. Another train my also set a route concurrently along the intended path and proceed in a likewise manner. This works well if the layout is designed such that all traffic is one-way. If part of the route permits two-way traffic, a "Deadlock" or two trains stuck facing each other could occur. Therefore, directionality of all tracks along the route must be evaluated before this type of locking is permitted by > 1 train for a given bi-directional route. Alternatively, the system would have to generate an "execution plan" whereby one unit goes into a siding at an intersecting point on the route to permit the other to pass.
