http://www.dmi.unipg.it/cp2011/cfa.html

We are looking for interesting papers describing running applications using constraint technology. There is still a month until the submission deadline, so start writing

Two guest blog entries in a row, do you see a trend here? If you have developed a constraint application and want to present it to the world in a non-technical way, get in touch!

The complex functionality that trading systems deliver makes testing them challenging. A tester with knowledge in the financial domain can generate test cases that cover the most usual trading scenarios, but it is practically impossible to come up with all the situations that will occur in production. At Cinnober, the company that develops the trading system TRADExpress, the manual generation of test cases is complemented with random testing, as an attempt to cover uncommon (yet possible) scenarios.

For random testing to be effective, an automatic mechanism that decides the correctness of each random test is needed. This mechanism is commonly called test oracle, and it can range from a simple crash check to an independent implementation of the system’s functionality.

At Cinnober fairly simple test oracles were used, which were only able to detect failures such as negative prices in trades and system crashes. Encouraged by previous success in applying random testing, we decided to develop a more complete test oracle. The test oracle would be accurate and cheap to develop and maintain, while covering a significant part of the TRADExpress functionality. As the core functionality of the system can be seen as a combinatorial problem (matching bid and ask orders placed in an order book), we chose to use a constraint model of it as the test oracle.

The functionality to test: continuous double auction

The main mechanism to match orders is called continuous double auction (CDA). In a CDA, orders are stored in an order book and matched against each other as soon as their constraints allow it. The main operations that a trader can perform are to enter, update and cancel orders. A trade order usually includes, at least, these attributes:

• Side (bid or ask)
• Quantity
• Minimum acceptable quantity
• Limit price (worst acceptable price)

Let’s see now how our CDA works through an example. Consider this order book, where orders are represented following the notation (quantity [>= minimum acceptable quantity] @ price):

In this state, no match between bid and ask orders is possible: the price limit constraint allows a1 to match only with b1, but this is not possible because the minimum quantity constraint of b1 cannot be satisfied. What happens if a trader enters a new order a2 with quantity 40 and limit price 24?

The new order a2 gets lower priority than a1 because of its worse limit price. But now a1 and a2 can satisfy together the minimum quantity constraint of b1. Therefore the orders are matched, resulting in b1 trading 15 units with a1 and 35 units with a2. After the trade, b1 and a1 are totally filled, and the quantity of a2 is updated:

The test oracle

As the example shows, the CDA problem is very naturally described in terms of constraints, and an optimization objective: to maximize the total traded quantity between orders in every match. This makes the implementation very direct, which is a good feature for a test oracle: a MiniZinc formulation of the problem captures the logic explained above in less than 100 lines of code! (get some example data files here). Note that the actual model used as a test oracle is, unfortunately, a little more complex: for example, it is decomposed into two steps to reflect the expected behavior of TRADExpress.

The outcome

The most interesting part came at the end, when we ran the tests: after a few random trader operations, the constraint-based oracle reported system failures! The failures were triggered by complex scenarios, which could not be anticipated by a more systematic process based on the manual selection of test cases. Such is the result of combining the innocence of random testing with the soundness of a constraint-based oracle.

To learn more

The complete model is given in the following paper:

• Testing Continuous Double Auctions with a Constraint-based Oracle, Roberto Castañeda Lozano, Christian Schulte, Lars Wahlberg. Sixteenth International Conference on Principles and Practice of Constraint Programming, 2010.

This application was developed as a master’s thesis between the Royal Institute of Technology (Sweden) and Cinnober Financial Technology AB. Further detail and background information is given in the master’s thesis report:

• Roberto Castañeda Lozano, Constraint Programming for Random Testing of a Trading System. Royal Institute of Technology, Stockholm, Sweden, Master thesis, TRITA-ICT-EX-2010:69, 2010.

Figure 1: Feature and Feature Types

Features are designed as independent separate module and are exposed through feature catalogs (see Figure 2). A user selects from the catalog the set of features that he wants to be active during the session in which he is involved. He may also want to sequence the activation of the selected features in a particular way to better suit his needs (e.g., he may want to filter his incoming calls before diverting them). The features that the user has selected plus the ordering constraints that he has imposed on them constitute the feature subscription of the user.

Figure 2: An Example of a Catalog

As features are designed independently, each feature is designed under the assumption that it is the only activated feature during the call. This assumption is what causes the interaction between features. A feature interaction is a way in which a feature modifies or influences the behavior of another feature in generating the system’s overall behavior. Undesirable interactions must be detected and avoided when users configure their subscriptions.

Figure 3: Example of Undesirable Feature Interaction

In Figure 3, we show an example of an undesirable interaction: Y has two features in his subscription: a “terminating call screening” feature and a “call forwarding unconditional” feature. Y has requested that the “call forwarding unconditional” feature must be activated before the “terminating call screening” feature. As the “call forwarding unconditional” changes the destination of the call, the “terminating call screening” feature is never activated. So when X calls Y, X will always be re-directed to Z, even if X is the list of banned callers. A simple fix is to inverse the order of activation (as shown in Figure 4).

Figure 4: Avoiding the Undesirable Feature Interaction

Key requirements that drive the design of feature-rich telephony systems are: the ability for users to parametrise features (e.g., “Call-Divert to mobile”), address caller and callee scenarios (e.g., “Do-Not-Disturb and Speed-Dial”), combine or sequence features (e.g., “Call-Screen then Call-Divert”), request context-sensitive feature configurations (e.g., “Mute during seminars”), and express preferences or priorities (e.g., call policies imposed on a workforce). Different approaches ranging from scripting to policy enforcement have been proposed to meet these requirements. None, however, provides a comprehensive personalisation solution to: resolve undesirable feature interactions arising due to compositionality; manage conflicting preferences; and handle the uncertainty inherent to context data. To address these issues we designed a system for Context-sensitive Configuration of Call Control features using Rules (4CRules) [3].

4CRules allows a user to describe the behaviour of the communication service through a set of Feature Configuration Rules (FCRs). Conceptually, a FCR is weighted and associates a context condition to a feature subscription, which is defined to be a set of features, and a set of precedence constraints prescribed by a user and the feature catalogue. Each time a user’s context is updated, the engine of 4CRules infers a sequence of features from his/her set of FCRs. %and a catalogue of precedence constraints. This sequence is free of undesirable feature interactions and it is applied to all calls involving the user until his context changes again.

A set of FCRs that are applicable for a given current context of a user could be inconsistent due to a variety of reasons as explained in [3]. The 4CRules engine computes a maximal subset of the applicable FCRs that is consistent and optimal in some sense. The optimality is based on a strict weak ordering over FCRs, which is obtained by evaluating a value for each FCR by combining priority of the FCR, concreteness of the context condition of the FCR, and probability of applicability of the FCR. The principle of the presented approach is to view FCRs processing as a constraint optimisation task. Overall, the method ensures maximum adherence to user requirements and interaction constraints.

Figure 5: Subscription Interface

Figure 5 shows a snapshot of the widget-based web interface to the subscription configuration system. The interface exposes the catalogue from which users can pick and sequence features through drag-and-drop operations and the context dimensions. The constraint engine then guides the user towards consistent subscriptions in different ways:

• verification: checking the consistency of the input subscription;
• partial completion: if consistent, extend it with entailed precedence constraints;
• filtering: if consistent, filter out the set of additional features and precedence constraints that would make it inconsistent;
• completion: if consistent, suggest complete and consistent extensions;
• revision: if inconsistent, suggest consistent and optimal relaxations.

These services are implemented by modeling and solving the feature subscription configuration problem as a combinatorial problem [4]. The constraint engine implements branch-and-bound and constraint filtering algorithms to compute relaxations and graph algorithms (topogical sort and transitive closure) for the other tasks. It is programmed with the Java-based constraint programming library Choco [2]. An alternative approach is to compile the catalogue into a binary decision diagram in the offline phase and based on the input of a user use polynomial time operations in the online phase [1]. The subscription interface is implemented using JavaScript, Java Server Pages and Ajax techniques. The service delivery platform is itself based on the Session Initiation Protocol [5, 6] with routers and features implemented as SIP servlets.

To learn more

1. Tarik Hadzic, David Lesaint, Deepak Mehta, Barry O’Sullivan, Luis Quesada, and NicWilson. A BDD Approach to the Feature Subscription Problem. In Prestigous Applications of Intelligent Systems (PAIS), Patras, Greece, July 2008. To appear.
2. F. Laburthe and N. Jussien. JChoco: A java library for constraint programming.
3. David Lesaint, Deepak Mehta, Barry O’Sullivan, Luis Quesada, and Nic Wilson. Context-Sensitive Call Control using Constraints and Rules. In Proceedings of the 16th International Conference on Principles and Practice of Constraint Programming, St Andrews, Scotland, 2010. Springer.
4. David Lesaint, Deepak Mehta, Barry O’Sullivan, Luis Quesada, and Nic Wilson. Developing approaches for solving a telecommunications feature subscription problem. Journal of Artificial Intelligence Research (JAIR), 2010.
5. Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, Alan B. Johnston, Jon Peterson, Robert Sparks, Mark Handley, and Eve M. Schooler. SIP: Session Initiation Protocol. RFC 3261 (standard), IETF, June 2002. Updated by RFCs 3265, 3853, 4320.
6. Robert Sparks. SIP: Basics and Beyond. ACM Queue, 5(2):22–33, March 2007.

I’m sure you will enjoy this description of the 4CRules system, and perhaps this will encourage others to show us their work as well

Tuesday

• 14:00 A Safe and Flexible CP-based Approach for Velocity Tuning Problems. Michaël Soulignac, Rueher Michel, Patrick Taillibert
• 14:25 Constraint Programming for Mining n-ary Patterns. Mehdi Khiari, Patrice Boizumault, Bruno Cremilleux
• 14:50 Testing Continuous Double Auctions with a Constraint-based Oracle. Christian Schulte, Roberto Castañeda Lozano, Lars Wahlberg
• 15:15 Global Constraints on Feature Models. Ahmet Serkan Karata¸, Halit Oğuztüzün, Ali Doğru

Friday

• 11:00 Contingency Plans for Air Traffic Management. Karl Sundequist Blomdahl, Pierre Flener, Justin Pearson
• 11:25 An Integrated Business Rules and Constraints Approach to Data Centre Capacity Management. Roman van der Krogt, Jacob Feldman, James Little, David Stynes
• 11:50 Load Balancing and Almost Symmetries for RAMBO Quorum Hosting. Laurent Michel, Alexander Shvartsman, Elaine Sonderegger, Pascal Van Hentenryck
• 12:15 Context-Sensitive Call Control using Constraints and Rules. David Lesaint, Deepak Mehta, Barry O’Sullivan, Nic Wilson, Luis Quesada
• 14:00 An Integrated Modelling, Debugging, and Visualisation Environment for G12. Andreas Bauer, Viorica Botea, Mark Brown, Matt Gray, Daniel Harabor, John Slaney
• 14:25 An Empirical Study of Optimization for Maximizing Diffusion in Networks. Kiyan Ahmadizadeh, Bistra Dilkina, Carla Gomes, Ashish Sabharwal

The best application paper will be presented on Wednesday

• 10:00 Distinguished paper (Applications Track) Applying Constraint Programming to Identification and Assignment of Service Professionals. Sigal Asaf, Haggai Eran, Yossi Richter, Daniel P. Connors, Donna L.Gresh, Julio Ortega, Michael J Mcinnis

I hope to learn more about these systems at the conference, and to perhaps convince some of the authors to guest-edit a blog post here. Stay tuned!

Need for BoD: 3D Seismic Data Analysis (from askchesapeake.com)

Why Schlumberger?

A Data Collector for Well Logging (Schlumberger)

Why is Bandwidth on Demand an important problem for Schlumberger? Schlumberger is one the of largest oil-field services providers in the world. Historically, well logging is at the core of its business, and today the company offers many different sensor packs that can be placed in the drill hole. The picture on the left shows such a sensor tool, which looks like yet another piece of pipe in the drill stack, but contains different types of sensors plus data collection and forwarding equipment, operating in one of the toughest environments imaginable. In modern well logging equipment, a multitude of data (up to 12Mbs is quoted) can be collected while the drilling is ongoing. Some of that data is used directly at the drill site for control of the drilling operation, but much of the data must be analyzed centrally in a data centre. Historically, the logging data (reels of data tape) would be sent by courier to the central office, as the network connection to the well head did not have enough capacity. Delays of several days would ensue. Modern VSAT satellite links and optical fibres along-side pipelines do provide enough capacity to carry this data to the network backbone. In the data centre the data is analyzed and visualized with a multitude of tools. The drilling operation is often controlled by a consortium of companies, all of which must be involved in the decision-making process. As their analysis experts are in very high demand, it is impossible to require physical meetings for these discussions. Instead, video conferencing supported by shared data visualization is used to connect multiple sites around the world. As the cost of drilling operations can be very high, all this IT infrastructure must work as advertised, i.e. faults in data collection, transport and analysis may not delay the drilling. One way of achieving this is by using a specialized, high-performance network.

A Global Enterprise Network

The dexa.net network was designed as a global enterprise network, providing connectivity to places that normal ISPs do not go, like off-shore oil fields, or seismic exploration ships. The “last mile” connectivity very often is by VSAT satellite link, but a global wired network connects centers of oil exploration and data analysis.

Schlumberger dexa.net Global Network

The image above shows a diagram of dexa.net from my CP-AI-OR 2004 tutorial. This is an enterprise network, not a carrier network. This means that the connection links are rented from telecoms, and are thus sized carefully based on current and future demands to reduce rental cost. Providing enough spare capacity for an unlimited number of well logging tasks is not economically feasible.

Cisco 12000 Series Routers (from Cisco website)

The network infrastructure is based on Cisco 12000 series routers, which offer the required MPLS-TE and DiffServ technologies. MPLS-TE (Traffic Engineering over MPLS (Multi-Protocol Label Switching) provides mechanisms to set up explicit paths between two network nodes, controlling which links are used in the connection. This by-passes the normal routing in the IP network, and gives more flexibility to the network engineer setting up the connection. DiffServ provides multiple traffic classes controlling the queuing in the router interfaces. This allows to favour certain types of traffic over other traffic types, for example making sure that video data is forwarded with (nearly) no packet loss, and low latency and jitter. If too much traffic arrives at some part of the network, other, less important traffic classes are dropped first, while quality of service for the important traffic types is maintained.

The BoD application uses these technologies to set up tunnels for new user demands for the time of their operation. This is an extension of the Demand Acceptance problem, adding a time dimension (fixed start and end) to each demand. Only demands which overlap in time compete for resources, while all demands compete with the normal traffic loads of the network. The tool therefore consists of two main components, a network analysis tool to predict the base load in the network at some future time point, and the routing module which tries to find paths for demands given estimated free capacities.

BoD: Network Hotspots Marked in Red

Note that user demands are not just single point-to-point connections, users typically request a VPN (Virtual Private Network) between multiple locations. This can translate into many point-to-point connections. Finding routes for only some of those binary connections is not enough, the user request will only be satisfied if all connections can be set up at the same time.

The BoD network operates under a first-come, first-serve policy: if a user has made a reservation, which was accepted, then we are no longer allowed to reject the demand at some future time, in order to allow other orders to be satisfied. If the connection has not yet started, we are able to re-route the path, as long as its QoS parameters stay satisfied. If the connection is already live, we are not allowed to touch it, as any modification could lead to loss of connection and unacceptable packet loss.  All these constraints mean that we can not solve this problem effectively if we only consider adding point-to-point demands one at a time. We must resolve the complete problem, where some of the previous solution is fixed, and previously accepted demands must be kept. Solving the complete problem for all time points in one step is often not feasible, so that a temporal decomposition must be used.

Gantt Chart Showing Accepted and Rejected Demands

To learn more

A mathematical description of the Bandwidth on Demand problem is given in chapter 25 of the Handbook of Constraint Programming on Network Applications.

A Short Article in Technology Ireland About CPTV

The work on CPTV (Constrained-Based Personalized TV Schedules) was sponsored by the Commercialization Fund of Enterprise Ireland, one of our national funding agencies, with support from the European Regional Development Fund. In the July/August issue of EI’s magazine, Technology Ireland, you can find a short write-up of the project on pages 14/15.

Please tell me about application areas you want to see more about. This will help me to focus on areas of interest to you!

The problem is about train crew diagraming for the regional trains services in the north-west of England, centered on Manchester. Most trains used are diesel-powered units like this one:

NWT Type 153 at Carlisle (from Wikipedia)

A diagram is a statement of work for an anonymous train driver or conductor (guard), describing all the work activities he has to perform from clock-on to clock-off. A typical diagram for a driver consists of around 12 driving tasks, and 16 non-driving tasks, like coupling/decoupling of units, preparing/shutting down a train, walking between platforms or between a siding and a station. It might also describe more complex movements between stations, either walking, driving by staff car, by bus or taxi, or dead-heading in one of the companies’ trains or using a train connection of a competitor. Each activity is governed by rules and union agreements, which have grown over a period of 100 years to a very complex set of rules and exceptions. A diagram always starts and ends in the same location, the crew depot. In our case, we have to deal with 12 depots of vastly different sizes, the largest centred on Manchester Piccadilly and Manchester Victoria (the two main stations in Manchester).

Manchester Piccadilly (from Wikipedia)

A priori, individual route segments can be performed by drivers from different depots, although restrictions on route knowledge and training apply. Drivers and conductors are often able to operate several of the different train types. The diagraming is not concerned with individual drivers, it only creates the diagram for some depot. Assigning the diagram to an actual person is the task of rostering, performed as a separate step.

Different diagrams are created for the Monday-Friday timetable, and for Saturday and for Sunday timetables. In principle they are valid for half a year, in practice a lot of changes are required for the weekend diagrams, as the dreaded “engineering works” require updates to many train operations. Changes are also required for special events, e.g. Manchester United playing in the Champions’ League on a Wednesday, with extra services to/from Old Trafford being needed. Before we started this project, a team of 10 crew schedulers was working full-time on making these adaptions, and planning the diagrams for the next timetable.

Manchester United Halt: Extra Trains for Game Days Only (from Wikipedia)

The route network stretches from Carlisle in the north to Birmingham, and from Holyhead (the ferry port to Dublin) to Sheffield in the north-east. There were even some long distance trains from Manchester to London Euston to consider. The map shows the major stations used, indicating only those locations where either train services start/end, or where crew can be changed.

View Larger Map

Overall this is a major operation, there are around 200 trains, and 700 drivers and 600 conductors to consider. The following figure shows the distribution of demand during the length of a day.

Demand During Day

The map above shows each station as a marker, this should not give the impression that they are all the same. We have seen a picture of Manchester Piccadilly above, it is the largest station in this part of the network, used by several other train operating companies as well. The picture shows the main hall, renovated to reflect its Victorian origin. At the other end of the spectrum we have a station like Bidston (below), which is the end point of the Bidston-Wrexham line, connecting Merseyside to North Wales.

The End of a Line: Bidston Railway Station (from Wikipedia)

A Changing Environment

We always claim that Constraint Programming is able to work in rapidly changing environments, but this was a bit much even for CP We started the discussions when the company was called North West Regional Railways,

Logo #1: Regional Railways

part of the British Rail empire, and close to being privatized. The logo changed with the privatization, when the company became North Western Trains.

Logo #2: North Western Trains

That logo did not stay long, it was replaced by this:

Logo #3: North Western Trains

Unfortunately, many other things changed as well. Ian Maclean from PA Consulting, working with us on the project,  described this in a talk at the Industrial Day of ICLP 98 in Manchester. Of the 23 persons we interacted with at the start of the project, only one was still in the employ of the company when we finished.

After a year of operating as an independent company, it was bought by the First group, a major bus and train operator in the UK. Logo number 4 followed quickly. As First already had operational systems for unit and crew diagraming, the need for our new system went away, and the project was shelved.

Logo #4: First North Western Logo

Lessons Learned

We learned a lot during this project, Phillipe Charlier and myself gave a presentation at the DIMACS workshop on Constraint Programming and Large Scale Discrete Optimization, September 14 – 17, 1998 on a “A system for train crew scheduling”, from which most of the material used here is drawn.

Data, data, Data!

We were aware of this problem before, but it still cost us months of hard effort. Before our project, the diagrams were generated manually, using basically a text editor, and were only used by humans. Humans have a much higher tolerance to errors than computers, and contrary to airlines, railways did not have rule checkers to validate the manual diagrams. We spent months finding errors and exceptions to rules, indeed we fixed the last problems in the week of the final acceptance test.

Closed World Assumption

A constraint program always operates under a “closed world assumption”. This term from Artificial Intelligence research means that the program does not have any common-sense background knowledge, it only reasons about the information it is explicitly given. For example it does not know whether two stations are close enough to walk between. If the constraint model does not contain such a connection, it will not attempt to use it. A human may decide to use a train of another company between two locations, the computer does not even know that other companies exist.

Depot Assignment

One of the most critical decisions for the system is which activities to assign to which depot. A wrong choice may lead to big problems later on, but that impact is not immediately visible when making the initial choice. Modelling the problem as assigning activities to diagrams ignores this decision, and often makes an inefficient choice.

Scalability Matters

Our constraint model used the cycle constraint in a similar form as described for the TAP-AI application for SAS. Activities and crew are the nodes, and there are connections between nodes if a connection is possible. But while the TAP-AI model used hundreds of nodes, we needed thousands of nodes to model this crew diagramming application. Unfortunately, the propagation methods inside the cycle constraint are quite expensive, this meant that run-times increased to hours, instead of minutes.

Solution Chosen

Over the project duration, we changed our model several times, in the end we used a decomposition with a set covering model to handle the depot assignment. In this model, we use the constraint model to generate candidate diagrams, and then use a MIP based set covering algorithm to select the best combination. In the set covering, we could also impose constraints on how many diagrams we allowed for each depot, to avoid cases where some depot is overwhelmed with work that could also be assigned to a less-utilized depot.

Once the depot assignment was done, we had a working solution for each depot. We then tried to re-run the model for each depot using constraint programming alone, in order to improve the solution. Solution quality is measured in the number of diagrams used, but also in total working time, and the balance between diagram durations. As we now only had to work with the tasks assigned to a single depot, and we knew the problem was feasible, we had a more manageable problem to solve at this step.

To know more

The definitive paper on solving the crew assignment problem for railways is from the Netherlands:

Leo Kroon, Dennis Huisman, Erwin Abbink, Pieter-Jan Fioole, Matteo Fischetti, Gábor Maróti, Alexander Schrijver, Adri Steenbeek, Roelof Ybema. The New Dutch Timetable: The OR Revolution. INTERFACES Vol. 39, No. 1, January-February 2009, pp. 6-17, DOI: 10.1287/inte.1080.0409

This system won the INFORMS  Edelman prize in 2008, for saving millions in operating cost of the Dutch railways. It is not using constraint programming, though. It would be fun to check if CP has progressed enough in the last ten years to threaten a classical OR approach, but better plan for a longish project.