Engineering Analysis

ORION Engineering Analysis and Design is intended for those areas of engineering poorly served by the current tools of computer aided engineering - areas where the required flexibility of the analysis precludes the use of highly structured algorithmic approaches.

ORION is a tool for handling knowledge, and particularly knowledge that is not easily crystallised in the form of CAD or Finite Element Analysis, or any other highly specialised tool. Tools like these can do an excellent job of providing manufacturing drawings, tool paths, estimating stress in a particular detailed design, but can contribute little to choosing among designs on the basis of the development risks involved, the robustness, durability, marketability, time to market.

ORION is not just a financial tool, but allows you to merge many factors into the high level decisions to be made, even while it is supporting the detailed analysis of a complex operational environment.

ORION Engineering Analysis provides the tools to permit a much more comprehensive approach to analysis of the options that confront any large engineering organisation, a new level of interactivity with the analysis, and a degree of mechanisation of the high level aspects unattainable with algorithmic methods.

These new tools handle tentative information and variable structure simply and efficiently, greatly increasing the scope and effectiveness of the analysis.

Why a New Technology To Manage Knowledge

There are many excellent engineering analysis tools, tools developed to implement specific algorithmic approaches to detailed design. We have programs for CAD, mathematical manipulation, parametric design, Finite Element Analysis, pipe flow analysis, communications network analysis, Project Management.

Most of these tools are intended for the back end of design analysis, where all the variability has been removed and we can specify precisely each piece of the design - we have already made all the important decisions and we can now analyse the elements in detail. If we run into insuperable problems at this detail level, the separate tools can only give us a hazy picture of how to go back and rethink the overall design.

With these current tools, there is a relatively rigid data structure which must be used to describe some aspect of our design, and an algorithm that "understands" and operates on that structure. What we have lacked is a tool which allows us to assemble components of the design at an early stage while much variability exists, in a way that can handle tentative information and isn't compromised by a data structure which is purpose built for a particular algorithmic approach.

ORION is a tool for knowledge handling. By describing the problem area in analytic terms, the user builds up a network of operators whose interaction represents the behaviour of the design and its environment, whether that environment be its operating regime, its life, reliability and maintenance requirements, its development and manufacture. The system works best when all these elements are combined into a high level description of the overall design, and the influence of competing requirements - low initial cost, high reliability, low running cost, can be examined.

The advantage that knowledge handling has over other forms of analysis is that the underlying structure is far more flexible and adaptable - as it must be, to handle the various things we want to describe - whether it be temperature rise, failure risk, or existence of some element. There are no given and immutable factors - everything must be modifiable in the analysis.

ORION has smoothly merged logical, numeric and object-based analytic descriptions into one structure, with bi-directional transmission of information among the operators responding to change on their inputs, and operators having the ability to modify the topology of the network around them. An important aspect of knowledge handling is that no potential inference can be lost in mapping from the textual form we use to the internal network.

Some Examples of Knowledge Handling

Several examples may demonstrate the lack of general purpose analytic tools. The examples come from the aircraft industry, because their designs are highly constrained and so exemplify the point, but you will recognise similarities with your industry.

We want to set up a model of elements of an engine and its operating regime. State transitions in the regime include laminar to turbulent flow, subsonic through trans-sonic to hypersonic, viscosity of a liquid changing with temperature, transition from vapour to gas. As we change the design and its operating point, we want the analytic equations that apply to switch in and out automatically, the switching being controlled at the same level as the rest of the analysis.

The resulting knowledge structure has very much of a wired up machine look about it, the spindling of equations being repeated for each state or regime transition. We can pass ranges of values through this structure, the distributors at the ends handling fragmentation of the ranges, transmission of fragments through the right paths, and the recombination at the other end.

We want to design a jet engine. There would be some new development involved, the use of components from other manufacturers, who may also need to develop the state of the art, we need to analyse the time to market for the design, the marketability based on capital cost, operating costs coming from operating point, which depends on thermal limits, which depends on..., maintenance costs, risk of in-service failure based on assembling failure patterns of components against the replacement schedule in preventive maintenance, risk of marketing failure. How can we pull together an analysis that includes all these factors, so we have an ongoing design plan that assists in design decisions, development planning. The currently available tools may handle some facet, but cannot support the synthesis needed to support the high level design process. We could put together a financial plan, but it would be hostage to many other decisions that lie outside it. High level design has many similarities with Portfolio Analysis, in that we are assembling complex objects with operating limitations, initial cost, operating cost, failure risk, source risk, operating life, into a cohesive whole - and we need to be able to analyse when our current portfolio needs revision in the face of technological change and competition.

We want to analyse which is the best new plane to add to our fleet, and when to add it. There are many factors - time to availability, risk of delay, operating costs, market perception, our market growth, maintenance costs. Comparing objects as complex as aircraft, and seeing how they interact with the present fleet, what the mixture should be, how the basis of the analysis changes as the investigation proceeds is a non-trivial problem, and yet there is no easy algorithmic answer, just as there is no obvious starting point, other than to set up a model of all the factors, constraints and interactions, and observe its behaviour through time.

How is Knowledge represented in ORION

We start with a simple ORION statement:

A + B= C

This statement is keyed into the ORION Editor by the user. The structure maintenance element of ORION will establish that it consists of:

Three variables, i.e. A, B and C

Two operators, i.e. Equals and Plus

The system will then store the statement in the network as shown (the green components indicate that ranges are being propagated):

The statement by itself has no "directedness", and neither does the network. Any of the variables in the statement could be found from the others, and the statement could be used as a test for equality. A statement can be directed, by using an assignment operator, or the other network devices in ORION that allow it to model the behaviour of a wide range of analytic statements.

The statement is controlled by the logical environment in which it finds itself through the EQUALS operator. The textual statement of A + B = C obviously has a logical context - ORION provides a default logical context for the entire model, but all statements operate within a logical environment (the SPINE operator in the diagram), potentially controllable by other statements in the model, leading to a layering and "shelling" of knowledge.

As more statements are added the network increases in size and complexity along with its ability to "understand" the problem area. The connections being established are providing the meaning of the problem. If tentative information is present, the addition of statements acting as constraints will reduce the range of alternative values.

As an example of a more complex use, the diagram shows a fragment of a Project Management or Strategic Planning model, where bi-directional interaction is occurring among, cost, time, duration and resource usage operators to control the existence of an Activity.

The Activity operator is monitoring its Start and Finish Date inputs to ensure its existence, and if existence is not possible, it will signal out of its control pin, potentially forcing the existence of another activity to take its place. Terms like "control pin" come naturally, because the network takes on an electronic circuit flavour, with signals rushing in all directions through a circuit that was wired up by describing the problem.

The network structure that allows considerable fluidity in the description of a design is made out of the same elements that make up the simplest arithmetic statements, and is using the same information transmission mechanisms. Some of the operators are considerably more complex than a simple PLUS, but the basic operation remains the same, each operator responding to change on its connections.

The network that represents the knowledge is visible and traversable, and can be examined in detail to audit particular effects. As the overall network becomes more complex, it becomes essential to be able to limit the range of effects while some part is examined for correct operation.

The Power Of ORION

ORION combines a powerful direct search/solve technique with consistent reasoning about what it finds. These techniques allow it to attack unbounded and many-layered problems where nomination of a high level goal may lead it to seek hundreds or thousands of subgoals requiring many different methods of logical and numerical analysis.

There are three basic methods of information flow that ORION can use, Direct Searching where no information is present in the network, Dataflow where information is driven along network pathways, and Consistent Reasoning where there is superfluous but inconsistent information in the network.

In the search/solve process, ORION co-ordinates and manages many important techniques, e.g.

Twisting, turning and retracing as it attempts to move information through the network made up of active elements in an effort to find a path to a solution.

The propagation of alternative values through the network, allowing operators to prune values and rebroadcast, with the effect that complex operators communicate with each other to reduce the problem space.

The layering of knowledge in the sense that the validity of statements or blocks of statements can be logically controlled from any level and from any distance in the network.

Generation of possible results where it is not possible to reason away the possibilities without constructing and trying them.

Dynamic reconfiguration of the network, making and breaking connections under logical control. This changing of the network topology allows for more inferences to be made than is possible with operators remote from each other.

Network growth, by forming and testing new connections as part of a Generate, Test, Backtrack strategy. The backtracking is using Change Image Storage, so every change, including structural alteration of the network, is backtrackable.

Active simulation, where objects in the network are created, pass through processing stages, and are destroyed or recycled. This technique simulates the operation of a processing plant or job scheduler.

The most powerful aspect of ORION is its generality in terms of analysis - whether it be structuring design equations or evaluating the best design option or stringing items in a sequence. At any time, and at any point in the network, new aspects of the analysis can be added, because there is no starting and ending point as there is for an algorithm.

The Knowledge Modelling Environment

Problem solving can be started before the problem is fully defined. Results can then be applied to an expanding definition of the problem. Knowledge is input into ORION directly using easy to understand analytic statements or drawings directed to describing the problem area, greatly improving the productivity of the designers and problem solvers in your organisation.

More complex problems can be solved because the ORION system automatically provides the appropriate structure for the solution - your people aren't bogged down in the "mud" of the problem, trying to see how to phase a solution method correctly when there are competing requirements and it is not at all clear what should be done first - the phasing resulting from the connections in the knowledge network allows the phasing to be embedded, rather than determined beforehand from outside the problem. It is much easier for an analytic operator inside the problem, responding to the states around it, to figure out what to do, than it is for you to predict what will happen as the analysis proceeds.

The resulting ORION knowledge base fits the problem rather than the problem being "distorted" to fit the particular software being used.

The ORION knowledge base can be "viewed" from many different directions during testing. In other words, there are no fixed input/output variables. Input/output definition is a dynamic run-time consideration. This flexibility is a direct result of not having to translate the knowledge into stack machine programs or directed Expert System rules.

ORION knowledge is easily and quickly seen and changed by users, so keeping the design specification live and up to date.

The knowledge about the area being analysed becomes general corporate property rather than residing in the minds of a number of individuals. ORION allows this knowledge to coalesce into an integrated whole because it has no predefined structure, only the structure of the analytical knowledge it is given.

The knowledge network will repay being continually worked on to improve its accuracy of representation of the design analysis, because the structure is the design analysis. As you work on it, your mental model of the design will also increase in sophistication, as you see effects from constraints and interactions you may not have thought of.

The ORION Knowledge Base Textual Editor

The ORION Textual Editor allows you to build and modify the knowledge network. The new text statements you make are examined for syntax, and if accepted, are immediately inserted in the network and values propagated. This means that you can check on your progress as you build the model, and any changes have the minimum effect on what you have already built and the states and values you have already found.

The network develops a complex structure as it grows. Just looking at the text doesn't let you easily see all the associations among variables. Other tools allow you to display the connections in the network and values for the variables.

The Knowledge Base Drawing Editor

The ORION Drawing Editor allows you to build and modify the knowledge network using the graphic interface. Pointing at an object and connecting it through links to other objects is both simpler and more intuitive than text, and yet allows you to easily construct symbols of increasing internal complexity, and continue to connect them in the same simple way, using cables to hide the details of the connections.

You can define new operators which are assemblages of more primitive operators, import whole models into a model, or replicate some structure many times. The network model develops a complex structure as it grows. The drawings you use to define this structure allow a layering, so there is a General Arrangement at the top, with increasing detail about the actual information processing structure as you move down through the layers of drawings.

Customised Interfaces

Special purpose interfaces can be easily created using existing examples - one shown here can be linked to time variables in the network for display of planning information, or linked to parameters, which can then be quickly manipulated using graphical tools.

The bulldozers permit constraints to be added at ends of ranges, the excavator digging out some part of a range. Another window, not shown, allows alternatives to be switched between true and false and off.

Concepts of High Level Analysis

A knowledge modelling tool like ORION uses techniques quite different to those you may be familiar with in algorithmic tools or programming.

Constraint Reasoning

Set up constraints - Temperature < Critical - and make sure that no constraint is ever violated. Constraints can be numeric, or involve logic - IF A < B THEN C > D, with the test or assertion as yet undecided. ORION's constraints use reasoning at the operators that make up the constraints, rather than treating the constraints as black boxes, so many more inferences are possible.

Consistency

If a constraint is violated, a logical error or inconsistency results. The inconsistency may be used to cut a range of values, or may require backtracking out of the decision that caused the inconsistency.

Ranges Of Values

A variable can have a singular value, say 5, or a range of values, say 5..25, meaning the variable can have any integer value between 5 and 25. Ranges can also vary negative to positive, to model reversible conditions. Interaction of a number of ranges at an operator can have subtle effects.

Forward Cutting

When optimising a design, there is usually a hierarchy of choices to make. One can either make each choice in turn, or propagate the effects of one choice to reduce the number of downstream choices. As a result of propagation, either the ranges of downstream variables are reduced, or inconsistencies are encountered, forcing an immediate backtrack without wasted effort. This technique can reduce the number of choices to be tried by a factor of thousands or millions, making the optimisation of complex analytic models possible.

This is one of the few heuristics in the workings of the model. Basically, try to evaluate the location where failure is most likely to occur first, usually the worst conflict among alternatives. Try to find and eliminate failure, as a means of finding success more rapidly.

Sometimes you need to make a decision, observe the effects, then dig yourself out of the resulting hole. An analytic system has the same need. If a decision leads to an inconsistency, the system must cleanly undo that decision, so that it can make another one. A system which uses the computer's stack for backtracking can save the values of all variables at each step, but then it can't interact with the user because it is stuck up its own stack. ORION stores what it is changing, including structure, then can interact with the user while still being able to backtrack from its current state.

Accurate and Responsive

A system for Design Analysis needs to be accurate in terms of its assessments, and responsive to change. Sometimes the change is slight, a small parameter change, sometimes the change is massive, with the structure of the design being hacked around. With a mixture of drawings, spreadsheets, and back of the envelope figuring, the executives managing the design need to decide what to do with virtually no useful input at a high level, then have the engineers and draughters scramble to bring the design up to date.

A Constraint Reasoning high level design, which is continuously "live" and interactive, and will immediately display any inconsistencies in it, allows the engineer to make rapid changes to the design or its method of implementation, knowing that the changes are not introducing errors.

A design environment is necessarily volatile. Delays in recasting the design increase the instability of the overall control of the design process and decrease the willingness of the engineers to explore better alternatives. Just as important is the need to prevent thrashing of the design. Parts can be frozen while the design process continues, or even unfrozen again if the advantages are compelling - the analysis for this also embedded in the analytic system.

The ORION High Level Design System can provide accurate and timely information, while allowing its design model to be drastically changed to reflect new goals and other new constraints on the organisation.

How Unique Is ORION

There have been many attempts over the last twenty years to create a computing structure, using the notion of wiring up active elements in the same way that electronic microcircuits can be wired together to create a complex circuit. When some problem area is being analysed, not many statements need be gathered together before we start to lose control of what it is that we are doing. Dealing with objects that exist and have connections and accountable influences is easier than dealing with the sequential rush of a program. The analogy of real devices and hardwired connections starts to break down when we want to represent knowledge this way, as knowledge is slippery and is not directed to a specific purpose, so it is poorly represented by a structure with fixed connections and fixed directions within that structure. Complex problems are continually changing their structure as we come to understand them more, so using a fixed structure to make programming of a solution easy eventually defeats the purpose of finding an answer to a complex problem.

Most attempts at creating a network representation have been restricted to dataflow, where known values are propagated through the structure. Constraint languages provide an undirected network, and (usually) move integer ranges around that network to represent the domains that particular variables may have. A difficulty is that dataflow by itself is easily blocked by loops, and can only handle a small class of problems. For many problems, there is no value to start, because you are not even sure of the structure to use, or the structure will change based on what values you find, making the dataflow paradigm alone quite inappropriate.

ORION is intended for a very broad class of problems, typified by structural change, whether designing an aeroplane or analysing a developing situation, or steering a large organisation through stormy and changeable seas. It is not intended, nor is its mechanism suitable, for the high speed stereotypical program, where the structure is immutable and every action can be known and pre-programmed, and the data transformation is usually simple or simplified to make it feasible.

ORION does compete with some specialised programs which run a high speed algorithm on a fixed data structure, such as integer programming. In this area there is a crossover between high speed and dumb, and low speed and "smart", or at least trying not to be dumb. As the problem grows complex, high speed is of little use against infinite possibilities. Most complex (interesting, or at least hard) problems can't be fitted into an algorithm/data structure solution because the structure is too variable and segmentation destroys the essence of the problem.

The ORION system has many strengths:

A Presentation on Knowledge Based Engineering

An application of ORION - ARIA