Hubbry Logo
XconXconMain
Open search
Xcon
Community hub
Xcon
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Xcon
Xcon
Xcon
View on Wikipedia
from Wikipedia

The R1 (internally called XCON, for eXpert CONfigurer) program was a production-rule-based system written in OPS5 by John P. McDermott of Carnegie Mellon University in 1978 to assist in the ordering of DEC's VAX computer systems by automatically selecting the computer system components based on the customer's requirements.

Overview

[edit]

In developing the system, McDermott made use of experts from both DEC's PDP/11 and VAX computer systems groups. These experts sometimes even disagreed amongst themselves as to an optimal configuration. The resultant "sorting it out" had an additional benefit in terms of the quality of VAX systems delivered.

XCON first went into use in 1980 in DEC's plant in Salem, New Hampshire. It eventually had about 2500 rules. By 1986, it had processed 80,000 orders, and achieved 95–98% accuracy. It was estimated to be saving DEC $25M a year by reducing the need to give customers free components when technicians made errors, by speeding the assembly process, and by increasing customer satisfaction.

Before XCON, when ordering a VAX from DEC, every cable, connection, and bit of software had to be ordered separately. (Computers and peripherals were not sold complete in boxes as they are today.) The sales people were not always very technically expert, so customers would find that they had hardware without the correct cables, printers without the correct drivers, a processor without the correct language chip, and so on. This meant delays and caused a lot of customer dissatisfaction and resultant legal action. XCON interacted with the sales person, asking critical questions before printing out a coherent and workable system specification/order slip.

XCON's success led DEC to rewrite XCON as XSEL—a version of XCON intended for use by DEC's salesforce to aid a customer in properly configuring their VAX (so they would not, say, choose a computer too large to fit through their doorway or choose too few cabinets for the components to fit in). Location problems and configuration were handled by yet another expert system, XSITE.

McDermott's 1980 paper[1] on R1 won the AAAI Classic Paper Award in 1999. Footnote 2 gave a humorous explanation for the name "R1" as "Four years ago I couldn't even say "knowledge engineer", now I ... [are one.]".

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Xcon

View on Grokipedia
from Grokipedia
XCON, also known as R1, is a pioneering rule-based developed in 1978 by John P. McDermott at for (DEC). Designed to automate the complex task of configuring VAX-11/780 computer systems, it ensures that customer orders include all necessary hardware and software components while avoiding incompatibilities. Implemented as a production system using the OPS5 programming language, XCON operates through thousands of "if-then" rules derived from the knowledge of DEC's technical experts. The system addressed a critical bottleneck in DEC's process, where manual configuration by technical editors often took weeks and was prone to errors costing the company millions annually. By , XCON was in regular production use, processing all VAX orders and reducing configuration time to hours while achieving near-perfect accuracy. Its success demonstrated the commercial viability of , saving DEC an estimated $40 million annually by the mid-1980s through error reduction and efficiency gains. Over time, XCON evolved to handle a broader range of DEC products, spawning related systems like XSEL for sales assistance and XCLUSTER for cluster configurations. As one of the earliest expert systems deployed in industry, XCON highlighted both the strengths and challenges of AI applications, including from domain experts and ongoing maintenance of its expanding rule base, which grew to over 10,000 rules by the late . Its architecture influenced subsequent AI developments, emphasizing modular rule sets and engines for in complex domains. Despite DEC's eventual decline in the , XCON's legacy endures as a benchmark for applied in enterprise settings.

Background and Development

Origins and Motivation

During the 1970s, (DEC) experienced rapid growth as a leading manufacturer, particularly with the introduction of its VAX-11/780 system in 1977, which significantly increased the volume and complexity of customer orders. These orders required manual configuration by human experts to assemble compatible systems from a diverse of parts, often leading to errors and delays in production. The configuration process was particularly challenging due to the need to ensure compatibility among approximately 420 components, including cables, modules, peripherals, and software options, without standardized packaging that could simplify assembly. Orders frequently arrived incomplete or inconsistent, exacerbating the risk of incompatible combinations that could render systems nonfunctional upon delivery. By 1978, these issues were acutely felt at DEC's manufacturing plant in Salem, New Hampshire, where configuration errors resulted in substantial time and cost overruns during assembly. John P. McDermott, a at , became involved in addressing this problem, motivated by the broader need to automate and capture the expertise of human configurators in a systematic way. In late 1978, McDermott began tutoring sessions with DEC experts to understand VAX configuration, leading to the establishment of the project in 1979 with a small team supported by DEC's funding. The initial prototype, developed as a rule-based amid the emerging field of such AI technologies in the late 1970s, contained around 250 rules by April 1979.

Creation and Early Implementation

The development of Xcon, originally known as R1, began in December 1978 at (CMU) under the direction of John McDermott, who aimed to create an for configuring Digital Equipment Corporation's (DEC) VAX-11/780 computer systems. McDermott spent 4-6 months learning the intricacies of VAX configuration through intensive interactions with DEC experts, including hands-on experience with PDP-11 and VAX systems, supplemented by studying extensive technical manuals. This phase was integral to the first development stage, which lasted approximately four months and resulted in an initial prototype containing around 200 production rules. In the second development stage, from mid-1979 onward, the system's expanded significantly through iterative reviews by DEC configuration experts, who provided feedback on the prototype's outputs for both simple and complex orders. By August 1979, the rule count had tripled to 772, enabling the system to handle more comprehensive configurations. Xcon was implemented using the OPS4 production system language on a computer, which supported its rule-based inference mechanism derived from the family of languages; subsequent upgrades ported it to OPS5 for enhanced performance. Initial testing occurred in and 1979, where the system was validated against 50 real customer orders averaging 90 components each, during which it fired over 1,000 rules per order and took about 2.5 minutes of per configuration. Experts identified and corrected 12 errors in the rule base, after which the system demonstrated sufficient reliability for operational deployment. Xcon entered production use in at DEC's manufacturing plant in , where it was integrated into the order-processing workflow to automatically generate configuration diagrams for assembly technicians, thereby streamlining the transition from sales orders to production.

Technical Architecture

Knowledge Representation

Xcon's knowledge representation is based on a production rule system, where expertise for is encoded as condition-action pairs in the form of IF-THEN rules. Each rule specifies conditions that must be met in the current system state, followed by actions to modify that state, such as adding components or recording decisions. In its early operational version around , the system contained approximately 772 rules, with about 480 dedicated to core configuration tasks, representing state transitions for assembling valid VAX orders. The component database serves as the static repository of , cataloging approximately 420 VAX parts using attribute-value pairs to describe their properties relevant to configuration. For instance, each entry might include attributes like module type, electrical connections, or compatibility constraints, enabling rules to query and match components dynamically. This structured format allows the system to represent the physical and logical interconnections of VAX hardware without embedding exhaustive procedural logic in the rules themselves. Working memory functions as a dynamic data structure that maintains the evolving state of the configuration process, storing the customer's order details, partial assemblies, and intermediate computations. Rule actions update this memory by asserting new facts, modifying existing ones, or retracting invalid elements, ensuring the representation reflects the current configuration at each step. The rules are organized hierarchically by configuration subtasks, such as backplane assignment and module placement; for example, rules like "PUT-UB-MODULE-6" handle the positioning of Unibus modules on specific backplanes, while others, such as "ASSIGN-UB-MODULES-EXCEPT-THOSE-CONNECTING-TO-PANELS-4," manage device assignments to avoid conflicts like incompatible electrical connections. This organization promotes modularity and prevents redundant checks by sequencing rules according to the VAX's architectural layers. Knowledge acquisition for Xcon involved eliciting expertise from Digital Equipment Corporation (DEC) engineers through structured interviews and analysis of configuration manuals, focusing on heuristics for component substitutions and necessary additions to complete orders. Experts reviewed configurations to identify errors, leading to the refinement or splitting of rules; this iterative tripled the between the initial and early deployment phases. The was implemented in OPS4, a production language that facilitated the rule-based encoding.

Inference Mechanism

The inference mechanism of Xcon is based on the recognize-act cycle implemented in the OPS4 production system language, where the engine continuously matches the conditions of production rules against elements in the , selects a single instantiation, and fires its actions to modify the working memory or output configuration decisions. This cycle repeats until no applicable rules remain or the configuration process completes, enabling incremental construction of valid system orders without intermediate storage of partial results. The holds dynamic state information, such as order components and constraints, derived briefly from the static production rules in the . To manage multiple eligible rule instantiations and prevent infinite loops, Xcon employs strategies that prioritize rules by recency—favoring those whose conditions match the most recently added elements—and by specificity, selecting rules with more detailed or restrictive conditions over broader ones. This approach ensures orderly progression through the configuration task, with an average fan-in and fan-out of approximately three rules per element, reflecting the modular structure of the rule network. Unlike generate-and-test methods that explore multiple hypotheses, Xcon avoids entirely by using the "" method, which leverages domain-specific knowledge to guarantee that each rule firing advances along a single valid path to a complete configuration. In terms of , each recognize-act cycle in Xcon takes about 150 milliseconds on contemporary hardware, with a typical 90-component order requiring around 1056 rule firings and totaling approximately 2.5 minutes of . The decision process traverses an average path length of about 800 nodes in the rule network, benefiting from the absence of search due to the method's efficiency.

Functionality and Operation

Configuration Process

The configuration process of XCON begins with the input of a purchase order, which specifies the desired components for a VAX-11/780 computer system, such as CPUs, memory modules, disk drives, and peripherals. The system retrieves detailed descriptions of these components from a database containing attribute-value pairs for each item, including electrical requirements, physical dimensions, and connectivity needs. At this stage, XCON scans the order to identify incompletenesses, such as missing cables, power supplies, or controllers necessary for functionality, and flags them for resolution without rejecting the order outright. The process proceeds through several sequential stages to build a complete blueprint. First, backplane filling occurs, where XCON assigns modules to available slots based on an optimal determined by factors like priority and data transfer rates; it selects appropriate types (e.g., 4-slot or 9-slot) considering pinning compatibility and power limits. Next, module assignment refines this by placing specific devices, such as disk drives to controllers or multiplexers to unibus slots, while ensuring spatial constraints like panel connections are avoided; if slots remain unassigned due to mismatches, the system may deviate from the optimal or add additional backplanes and cabinets. Interconnection planning follows, mapping out cabling requirements, including jumper cables and terminators, to establish links across buses like the synchronous bus interconnect (SBI), massbus, and unibus. Throughout these stages, compatibility checks are integrated, verifying hardware prerequisites, voltage/frequency alignment, and load capacities, with brief assessments of software compatibility to ensure ordered peripherals align with the . In handling inconsistencies, XCON proactively adds essential parts—such as power supplies or adaptors—to complete the configuration and suggests substitutions for invalid combinations, like incompatible module pairings that exceed power budgets or violate slot constraints, thereby maintaining order validity. The process culminates in diagram generation, producing wiring diagrams that detail spatial relationships and connections for assembly technicians, along with a validated (BOM) that lists all components, additions, and any substitutions. A representative example of the flow starts with unassigned slots in a for an order including multiple unibus modules, such as disk drives and terminal interfaces. XCON applies rules to fill slots sequentially: it first assigns a dual-port disk drive to compatible controllers, checking for available slots and load limits; if a subsequent module like a requires panel space that conflicts, it skips to a lower-priority compatible item, leaving slots unassigned temporarily before planning interconnections with appropriate cables. This iterative rule-firing cycle ensures a feasible blueprint emerges, ready for .

Components and Rules

Xcon configures key hardware elements of Digital Equipment Corporation's VAX-11/780 computer systems, including backplanes, Unibus modules, panels, cables, and peripherals. The system supports approximately 420 such components, each characterized by attributes like slot compatibility, power requirements, and interconnectivity constraints. For example, backplanes come in 4-slot and 9-slot variants with specific pinning types (e.g., for SPC or RK611 compatibility), where first and last slots exclude full-width boards; Unibus modules such as the RK611 disk drive controller or DZ11-B multiplexer require designated slots (e.g., 6 slots for RK611) and adhere to load limits; panels include multiplexer and laboratory peripheral types that share space with only one per allocation; cables like the BC05F-16 (16 feet) or BC11A-10 jumper ensure proper connections; and peripherals encompass disk drives (e.g., RP05-AA, supporting up to 8 per massbus) and tape drives (e.g., TE16-AE). These elements form typical orders of about 90 components, with heuristics guiding their assembly to avoid conflicts like exceeding Unibus length or power regulator capacities (e.g., 5V limits per cabinet). The core of Xcon's operation lies in its rule base, a collection of production rules encoding configuration expertise. Starting with around 200 rules in the December 1978 prototype, the set expanded to 772 by June 1980 to handle increasingly complex VAX orders. Of these, approximately 480 focus on direct configuration tasks, while 292 provide general . Rules perform functions such as substituting equivalent parts (e.g., replacing a 4-slot with a 9-slot where feasible, except in restricted positions), adding required supports (e.g., continuity cards for unfilled SPC slots or Unibus repeaters for extended lengths), and validating constraints (e.g., ensuring total power draw stays within H7101 regulator limits or massbus adaptor capacities do not exceed 4 per system). Exemplary rules illustrate these heuristics in action. The rule ASSIGN-UB-MODULES-EXCEPT-THOSE-CONNECTING-TO-PANELS-4 assigns dual-port disk drives to compatible controllers while excluding modules linked to specific panels to prevent spatial conflicts. Similarly, PUT-UB-MODULE-6 positions a terminal interface in a slot only if the slot is empty, the module's load fits within Unibus limits, and contextual conditions (e.g., proximity to related devices) are satisfied. These rules employ logical conditions in an IF-THEN structure, such as IF (slot is empty AND module fits power and load parameters) THEN assign module to slot, enabling efficient sequencing without exhaustive search. Such mechanisms update the iteratively, prioritizing optimal placements like sequencing DR11 and DZ11-B modules on the primary Unibus adaptor.

Performance and Impact

Operational Success

Xcon demonstrated high operational effectiveness shortly after its deployment, achieving error-free configurations in 95-98% of cases by , which significantly reduced the need for expert manual interventions in order processing. This accuracy level reflected the system's ability to handle complex VAX computer orders with minimal rule-related issues, as fewer than 1 in 1,000 orders encountered such errors by 1983. In terms of volume, Xcon processed over 500 orders in its first year of operation in 1980, scaling to tens of orders per week initially and reaching an annual throughput of tens of thousands of orders by the mid-1980s. An initial validation test in late involved configuring 50 recent VAX orders, where a team of experts identified 12 minor knowledge errors—all of which were corrected through rule modifications, allowing the system to produce fully accurate outputs upon reprocessing. Since its integration into DEC's manufacturing workflow in 1980, Xcon has operated continuously, with ongoing refinements ensuring reliability. The system's reliability enhancements contributed to the elimination of prevalent configuration errors that previously delayed assembly processes. By 1986, Xcon had expanded beyond its original focus on the model to encompass the entire VAX product line, including models like the and , through iterative rule base growth and system unification. This scalability was enabled by its rule-based inference mechanism, which supported efficient handling of increasing order complexity without proportional increases in processing time.

Economic and Organizational Effects

The deployment of XCON at (DEC) generated substantial annual savings estimated at $25 million by 1986, with early estimates indicating up to $40 million in the first year of operation through reductions in configuration errors, accelerated order fulfillment times, and diminished reliance on human experts for routine tasks. These efficiencies eliminated an entire step in the process known as Factory Acceptance Testing, allowing systems to ship directly from assembly with high confidence in accuracy. By automating the configuration of complex VAX and PDP systems, XCON processed tens of thousands of orders annually with 95-98% accuracy, minimizing costly rework and delays that previously plagued DEC's operations. Organizationally, XCON prompted significant shifts within DEC, freeing up configuration experts from repetitive manual work and enabling them to focus on higher-value activities such as and . The system's maintenance initially required a small dedicated team of about two specialists, which expanded to eight by the mid-1980s as the rule base grew to over 6,000 entries, reflecting DEC's investment in specialized AI development. This centralization enhanced and skill specialization, transforming the configuration process from a decentralized, error-prone effort into a more controlled and scalable operation. Customer satisfaction improved markedly due to fewer delivery delays and more accurate system deliveries, as XCON ensured 99% of configured systems arrived complete and functional, reducing on-site issues and support calls. On a broader scale, these gains bolstered DEC's competitiveness in the rapidly expanding market throughout the , supporting higher order volumes and market share growth during a period of intense industry rivalry.

Evolution and Maintenance

Following its initial deployment, XCON's rule base expanded significantly to accommodate the increasing complexity of DEC's VAX product line. By the mid-1980s, the system had grown to approximately 2,500 rules, reflecting the need to handle a broader array of components and configurations. This growth accelerated, reaching 6,200 rules by 1987, as DEC introduced new hardware options and refined configuration requirements. Approximately 50% of the rules required annual modifications, primarily driven by frequent hardware updates that necessitated adjustments to ensure compatibility with evolving VAX models. Maintaining XCON proved challenging due to its scale and . The system's became evident when adapting to new VAX models, as the large, non-homogeneous rule base made it difficult for knowledge engineers to predict outcomes of changes, often leading to unintended side effects such as run-time errors or unwanted rule interactions. Updating rules frequently introduced errors, including retained unnecessary functions from copied rules for new devices, exacerbating the "rat’s nest" of special-case rules that degraded overall integrity. High maintenance costs arose from the need for a dedicated team of knowledge engineers—eventually numbering eight—to manage these updates, contributing to reluctance among developers to modify the system without thorough analysis. To address these issues, XCON underwent upgrades in the mid-1980s, including a reimplementation from OPS5 to RIME in the late 1980s, which aimed to improve maintainability and organization of the rule base. By this period, it was integrated with complementary expert systems like XSEL for sales assistance and XSITE for site planning, enabling a more streamlined workflow from order entry to deployment. XCON's decline coincided with DEC's broader market challenges in the 1990s, including the company's loss of dominance in minicomputers amid the rise of personal computing. The second AI winter (1987–1993) further diminished support for expert systems like XCON, as funding and interest in rule-based AI waned due to perceived limitations in scalability. Following DEC's acquisition by Compaq in 1998, XCON was phased out as the VAX line was discontinued and configuration needs shifted to newer architectures. Despite these challenges, XCON's foundational contributions were recognized posthumously; John McDermott's 1980 paper on R1 (the system's original name) received the AAAI Classic Paper Award in 1999 for its influence on production rule systems.

Influence on AI and Configuration Systems

XCON, deployed by (DEC) in 1980, stands as one of the earliest commercial expert systems to enter production use, validating the practical viability of rule-based for complex configuration tasks. Developed initially with around 750 rules to automate VAX computer order configuration, it demonstrated how AI could reduce errors and streamline industrial processes, paving the way for broader adoption of expert systems in manufacturing and beyond. This pioneering application highlighted the potential of production rule systems to encode domain-specific expertise, influencing subsequent developments within DEC and the wider AI community. The success of XCON directly inspired related systems at DEC, including XSEL in for sales configuration and XSITE in for site preparation planning, which extended rule-based techniques to complementary aspects of product deployment. These spin-offs not only amplified XCON's impact within DEC but also contributed to global AI applications by showcasing scalable knowledge representation for configuration problems. In the broader AI landscape, XCON underscored the value of —the process of eliciting and formalizing expert knowledge into rules—fueling the 1980s through investments in technologies. However, its rapid rule growth, eventually exceeding 10,000 rules, exposed limitations in and , prompting refinements in AI methodologies. XCON's legacy endures in modern configuration technologies, where its rule-based approach has evolved into more robust constraint-based configurators that handle complex interdependencies more efficiently. Contemporary product configurators in industries such as automotive and software draw parallels to XCON by using AI to generate valid, optimized assemblies from customer specifications, often integrating constraints to avoid the brittleness of pure rule systems. Academically, XCON serves as a seminal in AI literature on production systems and configuration challenges, illustrating both the triumphs and hurdles of knowledge-intensive AI applications.

References

  1. https://dl.acm.org/doi/10.1145/62065.62067
  2. https://hbr.org/1988/03/putting-expert-systems-to-work
  3. https://cdn.aaai.org/AAAI/1980/AAAI80-076.pdf
  4. https://aisel.aisnet.org/cgi/viewcontent.cgi?article=2128&context=misq
  5. https://ojs.aaai.org/aimagazine/index.php/aimagazine/article/download/100/99
  6. https://link.springer.com/content/pdf/10.1007/978-1-4613-1065-5.pdf
  7. https://www.jstor.org/stable/248770
  8. https://web.cs.wpi.edu/Research/aidg/CS540/papers/McDermott-R1-XCON.pdf
  9. https://apps.dtic.mil/sti/tr/pdf/ADA223957.pdf
  10. https://www.holloway.com/g/making-things-think/sections/the-ai-boom-19801987
  11. https://stacks.stanford.edu/file/druid:rq429th4300/rq429th4300.pdf
  12. https://misq.umn.edu/misq/article/14/2/127/1034/An-Examination-of-the-Impact-of-Expert-Systems-on
  13. https://time.com/archive/6711938/technology-putting-knowledge-to-work/
  14. https://stacks.stanford.edu/file/druid:rk795nw8403/rk795nw8403.pdf
  15. https://www.nap.edu/read/6323/chapter/11
  16. http://faculty.ist.psu.edu/vhonavar/Courses/ai100/Lecture14.pdf
  17. https://cdn.aaai.org/AAAI/1987/AAAI87-148.pdf
  18. https://apps.dtic.mil/sti/tr/pdf/ADA276686.pdf
  19. https://arstechnica.com/gadgets/2023/10/long-gone-dec-is-still-powering-the-world-of-computing/
  20. https://www.holloway.com/g/making-things-think/sections/the-second-ai-winter-19871993
  21. https://aaai.org/about-aaai/aaai-awards/aaai-classic-paper-award/
  22. https://www.bighuman.com/blog/history-of-artificial-intelligence
  23. https://ojs.aaai.org/aimagazine/index.php/aimagazine/article/download/460/396
  24. https://www.researchgate.net/publication/260036713_A_Short_History_of_Configuration_Technologies
Add your contribution
Related Hubs
User Avatar
No comments yet.