Welcome to the world of Knowledge Bridge (kBridge). This Concepts section is Designed with two purposes.
First, you can read it through from start to end to gain a better conceptual understanding of kBridge.
Second, the various explanations of kBridge-related concepts are hyperlinked to the Self-Guided Training so that as you go through the training, you can get quick access to relevant concept explanations.
We recommend that you read through this concepts section first, to get a good understanding of kBridge, then go through the Self-Guided Training section, referencing to the concepts as needed.
However, if you prefer a more hands on approach, it is perfectly acceptable to go to the Self-Guided training first and go through it with frequent reference to the concepts section. Either approach can work.
The Backstory
Historically, engineering tools have evolved from paper and pencil, to 2D drawing-based CAD, to 3D CAD, to 3D parametric CAD. This evolution has resulted in computer representations that contain more and more information about the object that is being Designed. The problem is that this is mainly information about what the object is, and not information about why or how the object is Designed.
[Possible illustration showing the progression]
Parametric CAD takes a small step in the direction of representing ‘why’ but is primarily limited to variables that represent dimensions on the object.
The fact is, to go to the next level — a level that enables a quantum leap in the help that computers can provide to engineers — you have to be able to represent the ‘why’ behind a Design, and you have to represent that ‘why’ in a way that the computer understands and can act on.
We call these explanations of ‘why’ Rules, and we call our new approach to engineering Rules-based engineering.
[Illustration showing the ‘why’ in the middle – Rules – and outputs as the spokes]
The genesis of any product starts with the ‘why’. The geometry, drawings, CNC, BOMs, reports, quotes, and so on are simply a result of applying the ‘why’ to problem-specific or customer-specific Parameters. If we capture the ‘why’ in an executable form, then we can:
▪Automate Design
▪Iterate for Design optimization
▪Reduce Mistakes
▪Improve Productivity
▪Reduce Design (throughput) Time
▪Enable Non-Engineers to Design or Quote
This isn’t a totally new concept. In fact, the first Rules-based engineering systems were developed in the 1980’s under the monickers of "Knowledge-Based Engineering," "Design Automation," or "Rules-Based Engineering."
These systems did a good job of representing engineering knowledge and automating it, but were so inaccessible (expensive, hard to use, not integrated with the rest of the world) that they failed to succeed in any meaningful way.
They did, however, have the powerful underpinnings needed. This includes concepts that we will discussing in more detail below, including:
▪Object Orientation
▪Inheritance
▪Declarative Style
▪Dependency Directed
▪Demand Driven
▪Hierarchical
▪Sub-assembly Parameterization
Team software is required
One of the reasons that these early systems failed stems from the fact that engineering is a community endeavor, not an individual act. Sure, one engineer can have the knowledge to Design one element of something, but it is extremely rare that one engineer can cover it all. Today, 99% of engineering tasks are solved by teams.
As an example, think of a ‘simple’ toaster. What could be simpler, right? To Design a toaster, and to Design the manufacturing facilities that are needed to make a toaster, we would need a whole book to list the engineering specialties:
•Metallurgy
•Electrical conductivity
•Thermal heat transfer
•Structural analysis
•Lighting Design
•Spring dynamics
•Plastics
•Manufacturing engineering
•… and so on
https://gizmodo.com/5794368/why-its-harder-than-you-think-to-make-a-simple-toaster
Collaboration and sharing are fundamental to engineering. The early Rules-based engineering automation systems did not support collaboration and sharing very well, if at all.
To be fair, the incredible information transport medium we have today for collaboration and sharing, the Internet, wasn’t around back then. Even basic mechanisms in software for modularizing and combining shared elements of engineering Rules were not in place at that time.
