Knowledge Architecture - A Fundamental Approach
By Ray Anderson, Lead KBE Engineer

KNOW

The primary source of all data for Knowledge Engineering is the Subject Matter Expert (SME).  These experts must be exposed to a culture of peer-to-peer discussion where they must have the maturity and presence of mind to argue their points of experience logically and constructively. No single point of reference suffices an SME opinion worthy of being entered into a knowledge database. These data points must be thoroughly critiqued and corroborated by not only experience, but recorded evidence of their validity.

The data points primarily contributed by SME’s are methods, heuristics, and proofs.  Briefly, ‘Methods’ refers to a procedure or sequence of events that is deemed the most efficient way of performing a given task. When these methods are found to split into derivatives, each branch must be completely and accurately defined as what is commonly known as ‘options’. At the top of each derivative branch there should be a set of contributing attributes that are capable of delineating the decision criteria for these branches. If branches are found to merge near or at the following output, an opportunity for standardization and workflow compression has emerged.

Heuristics, by definition are also called ‘Rule of Thumb’. Most cultures embrace heuristics as a way to expedite decision making and thus reduce resource requirements. However, unconditional heuristics would have left us with stone wheels rather than pneumatic tires. Heuristic attitudes toward problem solving are the enemy of innovation and competition, which is what we as corporations are known to thrive on. A competitive Knowledge Based Engineering (KBE) system must force SME’s to compete with one another and even corporate competitors, to cause a differentiation of KBE thought and culture. This differentiation is what will cause growth and opportunity for both the individual and corporation.

Proofs are data points that are based on target values and physical laws and relationships that do not change beyond accepted ranges for any reason. Examples of proofs are gravity, the relationship between atomic weights and gravity to derive mass, or the targeted Six Sigma range for a given process result.  As you might imagine, Proofs are the most tightly controlled and non-negotiable data points in a Knowledge Management System (KMS).

ORGANIZE

Within a KMS, all of the data points must be organized via attributes, so that an SQL (Structured Query Language) search can be performed on multiple attributes. The need for multiple attributes is evidenced by attempts to find data points that are not completely described. SQL allows the user to find the proverbial “needle in a haystack” by searching for attributes such as “Steel”, “1.25 inch”, “Thread”, and “Sharp”.  The resultant feedback could still yield a knife blade that belongs to a small knife, except that the “Thread” attribute has effectively refined the search.  I used this example to demonstrate that most SQL searches are only effective if the person that defined the attributes was thinking one step beyond the obvious description for a needle. If the shank of the blade had been threaded for attachment to its handle, further refinement of the needle attributes might be required. Such refinements can be captured real-time by the SQL itself, in learning systems. By not accepting more than one result, a Learning System (LS) could record which of the results you chose, and prompt for the criteria by which you chose it, such as “.8mm Diameter”.  After edition of the SQL, the LS would retrace the SQL and show you the “Needle” as the only result possible. Subsequent queries can now present you with all possible attribute options in a “Wizard” format.

The attributes common to a KMS that support KBE are Manufacturing Rules and Ranges, Cost Abatement Criteria, Six Sigma Measurements on Parts and Processes, Part and Assembly Functionality, Package Containment and Space Claim Requirements, Attachment Methods, and Aesthetic Theme.  Each of these attribute tables must be defined on every data point, so that the SME is reminded to think about the relationships between them. When relationships are found, links can be built from one data point to another, defining a neural network construct, which will result in a more robust understanding of the task or decision at hand.

COMMIT

As you can see, the need for expertise in database management and data point entry is critical to the success of knowledge management. Due to this need, Process Owners (PO) must be defined, and will need to be empowered to interact with the subject matter experts in order to objectively measure the effects of design and manufacturing process changes. Process improvements cannot be accurately or safely measured without a full understanding of the expected impacts. Every opportunity for improvement must be assessed, tested and measured individually, to avoid noise in the measures.

As each process change is shown to generate an improvement, requisite changes will be found, and will need to be weighed against the expected benefits of the process change as a whole. This stage of the analysis will hone both the skills of the SME’s and PO’s as well as require retraining of personnel and documentation edition. Once the process has been improved, and the expected benefits are realized, it is necessary to study automation.

In this stage, opportunities for automation will often emerge on their own, but must also be carefully considered. Impact assessments will reveal the amount of time saved by automation if and only if a complete prototype code can be generated. This code does not have to be completely stable, but must follow the process in order to validate its efficiency. Often, in the automation stage, a programmer will discover more opportunity for improvement. These opportunities must not be integrated without the SME’s and PO’s studying the process as a whole to verify that critical tasks are not being compromised.

EXCEL

In this stage, the SME’s perform another task. It now becomes their responsibility to populate the database with data points and heuristics, on a daily basis. It is also the point at which supporting logic and methods are entered separately, and linked to their related DB content. At this time, more opportunities for automation and DB Architecture improvements will emerge. These are also considered process changes, and must be reviewed as such via an Impact Assessment.

THINK

This stage of Knowledge Engineering is the point at which the Computer Aided Design (CAD), Computer Aided Machining (CAM), and Product Data Management (PDM) Systems should become connected to the vast vault of the knowledge database. This is where the validity of the data and its format of attributes, queries and outputs culminate in real, measurable value. Applications, Interfaces (GUI’s), and Reports become the focus at this stage.

Examples are the linkage of the CAD System(s) to the KDB, in order to run process compatibility checks, populate parametric fields, generate relationships between parameters, provide search engine capabilities with DB connection to results, and report generation.

CAM linkage to the KDB provides machinability checks, tooling compatability checks, G-Code subroutine retrieval and reuse, Six Sigma feature checks, and report generation.

PDM linkage to the KDB provides an understanding of what components may already exist to satisfy the design requirements, what processes are related to this component, what costs are associated, and what plant capacities are associated.

EXECUTE

This is the stage at which a complete statement of work (SOW) is prepared for the DB change requirements and Automation Code. In both cases, the required changes and code generation have already been tried and proven as prototypes against a Beta KDB, CAD, CAM, and PDM system.  The need for Beta environments has been proven a necessity for many years. No software development should ever occur on production environments or data, due to the risks associated with experimentation, such as securities, inwork deliverables, stability, and the lurking unknown.

A project manager must closely monitor the development of automation code. In most cases, the process owner should serve as the project manager, since the success or failure of the project directly affects their workflow. Important components of the SOW are the Source Code ownership, Documentation, Roles and Responsibilities, and accurate records of Milestone Performance. Also, the SOW should state that each time a new change in capability within the DB or GUI is required, it must be weighed against a pre-negotiated change tolerance and cost model prior to implementation.

When the value of these Automations and DB changes are being measured, they must be considered as a component of a larger plan. Their value assessment may show that in and of them there is little value, or even a deficit, but may be a prerequisite for a long term automation or DB capability that far outweighs the shorter term deficit. This requires the foresight and budgetary tolerance of what I call “Cost of Glory” (COG). This is usually the missing COG in the financial machine that almost always requires an immediate Return on Investment (ROI).

The fallacy in short term strategies can best be compared to raising children, when you consider that knowledge management is an attempt to feed enough relevant data into a “Brain” of child processes to feed “Thought” in the form of SQL, Linkages and Automations to “Execute” and achieve results that when “Measured”, prove to be both valid and efficient.  The difference is that while we understand child-rearing as a 18-25 year process, knowledge management and engineering is often understood to be a 2-5 year process, at which time the success is measured while it is still in it’s infancy, or even in vitro, if resources have been restricted or diminished. Decisions based on this early measure will usually result in a Board of Director decision to eliminate the waste in order to maximize profits in the short term.

There must be a completely unanimous decision by the Board of Directors to commit to a long-term strategy of growing a completely capable KDB System, and stability of direction for the term of that commitment in order to succeed. The Board must ultimately be the doting Grandparent of this child, for it to be successful in its enormous endeavor of becoming smarter and more successful than all of its competitors. Also, to hold this status, a continual process of improvement and reinvention must be considered when new methods emerge from the rapid technological evolution that is continually accelerating.

Machine Assisted Intelligence

In summary, I leave you with a thought provoking theory: The name that I have given the concept of a fully developed KMS/KBE/PDM System is Machine Assisted Intelligence (MAI), and includes a component that I have not even discussed in this article. That component is Derivative Decision Management (DDM), and is based on a neural network thought process. MAI is completely devoid of emotion, but inclusive of social and economic impact assessment, as well as all of the data points considered by the KDB in the generation of components and assemblies.