Knowledge-Based Systems Manufacturing With Viability Ensuring

With highly increased competition, intelligent product manufacturing based on interpretable knowledge bases has been recognized as an effective method for building applications of explainable Arti�cial Intelligence that is the hottest topic in the �eld of Arti�cial Intelligence. The success of product family directly depends on how effective the viability mechanisms are laid down in its design. In this paper, a systematic cloud-based set of tool family is proposed to develop viable knowledge-based systems. For productive participation of domain and cognitive specialists in manufacturing, the knowledge base should be declarative, testable and integratable with other architectural components. Mechanisms to ensure KBS viability are provided in an ontology-oriented development environment, where each component is formed in terms of domain ontology by using the adaptable instrumental support. Due to the explicit separation of ontology from knowledge, it became possible to divide competencies between specialists creating an ontology and specialists creating a knowledge base. We rely on the fact that the activity of creating an ontology is signi�cantly different from the activity of creating a knowledge base. Creating an ontology is a creative process that requires a systematic analysis of the domain area in order to identify common patterns among its knowledge. The characteristic properties of knowledge-based systems related to viability are described. It is explained, how these properties are provided in development environments implemented on cloud platform. The concept of a specialized manufacturing environment for knowledge-based system is introduced. The necessary set of tools for such ontology-oriented environment construction is determined. The example of tools for creating specialized manufacturing environments is the instruments implemented on the «IACPaaS» platform. The IACPaaS is already used for collective development of thematic cloud knowledge portals with viable knowledge-based systems. This specialized manufacturing environment has enabled the creation of multi-purpose medical software services to support specialist solutions based on knowledge being remotely improved by experts.


Introduction
The developer of any Software System (SS) has the task of create a software product, which meets all current requirements, but in addition he must also providently designate and put the mechanisms into it, which will provide further maintenance to meet the changeable user requirements to the interface, functionality, subject knowledge and service conditions.
According to the experts' estimations for the maintenance process can take a signi cant share, from 50 % up to 80%, in software system life cycle, which is quite signi cant amount (Selby 2007 Glass and Noiseux 1981), but according to some reports they could reach even 80%-90% (Islam and Katiyar 2014). Although it is known that some types of SS (such as rmware), do not require the maintenance (Pressman 2010).
SS modi cation is due to changes of operating conditions, user requirements, subject area etc., but whether it will be required or not depends on SS assignment, its uniqueness or from type of information being processed.
If consider the applied SS (including KBS), and also SS applications shells and tool software, the required SS modi cation could be estimated as follows.
Applied SS are created and purchased for professional activity support, customer service improving or for training purpose.
In the process of applied SS operating there the need in mistakes correction, new user-de ned functions adding, adaptation to new instruments/devices/platforms, user interface changing and information format clari cation.
The same thing is to the tools for applied SS development.
In case of the applied KBS related to traditional intelligent tasks such as diagnostics, planning, forecasting etc, the situation is different. Here it is rather expected the knowledge variability and new solutions appearance such as new diagnostic methods creation and new in uencing factors identi cation than just the user functions expanding.
The reason is that many known tasks statements in diagnostics, planning, etc. are quite stable, and new intellectual challenges are just the concretization or re nement of the existing ones.
The applied SS development or modi ability also depends on the development tools.
For software systems with the predetermined architecture, provided by frameworks and shells, the different components' maintaining and combining is markedly easier. It's because the problem of adaptability to devices, platforms, User Interface (UI), exibility, and to the stored or new information format is "transferred" to the mentioned tools.
The frameworks, shells, tool environments themselves are subjects to adaptation and expansion within their lower level language environments. At the same time, the required tools components can be both "own" and borrowed or integrated from other tools. For example, the architectural essential elements such as the object model itself, the data model, the component model are designed at "Rational Rose" tools environment, but the user interface is designed at the "Delphi" environment with conversion to "Rational Rose" Model program code.
The approach to applied software systems maintenance is similar to development tools maintenance, i.e. tool systems supporting.

The Features Of Knowledge-based Software Systems
KBS is a class of software (one of the classes of AI systems), the speci c features of which require specialized development and maintenance tools, which makes traditional maintenance methods ineffective. Unlike other types of systems (including AI systems), KBS explicitly distinguishes between information-data and information-knowledge.
Data is the operational input information for a task that describes the objects, processes, and phenomena of the domain, as well as their properties (can be stored in databases/facts).
Knowledge is the result of a person's theoretical and practical activities, re ecting the accumulation of previous experience. Knowledge is the regularities of the domain (principles, relations and regulations) necessary for solving problems based on new data (facts).
If the knowledge is isolated and formed into an independent architectural components -knowledge base, then the SS that uses it becomes KBS. Knowledge should be formed and maintained by domain experts (possibly with knowledge engineers and cognitive scientist), who become, in addition to programmers, designers, and other traditional types of software developers, full participants in the development and maintenance process. This requires them to be represented in the form understandable to domain experts.
In explainable Arti cial Intelligence (AI), an explanation of solution should be understandable and su ciently detailed, and formalized knowledge should be interpretable.
The speci cation of a task based on knowledge bases is the predicate P (x, k, y), where x ϵ X, k ϵ K(X, Y), y ϵ Y. A feature of the speci cation of the problem is that the statement about the existence of solutions is not valid (Gribova and Kleshchev 2014). It is assumed that there is a "correct" knowledge base k* ϵ K(X, Y) such that ∀ x ϵ X ∃ y ϵ Y P(x, k*, y); however, this assumption cannot be proved. In the general case, this "correct" knowledge base is unknown, and for any other knowledge base the statement about the existence of a solution does not have to be true (Gribova and Kleshchev 2014). But assuming the validity of the "weak" statement (about the existence of the "correct" knowledge base), it is possible to develop an algorithm for solving the problem (implementation in the algorithmic language of a partially de ned functional mapping A: <X, K (X, Y)> → Y) (Gribova and Kleshchev 2014).
Such problems in modern KBSs are solved "using heuristics, including empirical induction, analogy and deduction" (Finn 2014), often using more than one method of imitating human intellectual activity (Gavrilova et al. 2020). Modern KBSs offer a convenient user interface, they can receive data from measurement instrumentation and are often integrated with statistical and other software components that do not use formalized knowledge (including standard software packages) (Rybina et al. 2011;Rybina 2008).
The viability for a knowledge-based system is the providing its e ciency and usefulness in conditions when the domain (more often -knowledge, less often -ontology, functioning environment and user interface) are changed.
Since the viability of KBSs is manifested, rst of all, in the conditions of variability of domain knowledge, and "the ability to adapt in accordance with a change in the set of facts and knowledge" is considered one of the aspects of intelligence (Finn 2014), for most domains associated with solving intellectual problems, it implies the evolution of knowledge. Moreover, in domains where the in uence of factors and events on the state of the system (object, situation), their change in time, the in uence of individual characteristics of the system and some of its processes on others is important, the development / evolution of knowledge bases is the main "challenge" of modern "conditions" in relation to KBSs.
Continuous improvement of the knowledge base allows us to hope for a "reference" knowledge base k* ϵ K (X, Y). Its relevance (compliance with current knowledge) and quality will determine the success of the use of KBS (to obtain an explanation of y ϵ Y for any x ϵ X).

The Viability Model Of Declarative Knowledge Systems
The main task required for the solution is how to ensure that the knowledge base corresponds to the current knowledge in this domain and how to ensure their continuous improvement. , adaptability -using KBSs machine learning methods (means of inductively generating knowledge from selected precedents, means of knowledge discovery from "big data", or a combination thereof).
The "success" of adaptability (interactive change) depends on the domain ontology and the user interface of the knowledge base editor, which must meet the requirements and expectations of domain experts. At the same time, the ontology is a structural basis of both tools for experts (editing tools) and software components of KBSs (solvers of intellectual problems and user interfaces).

Architectural properties of systems based on declarative knowledge
In the domain ontology, the types of statements (allowing solving domain problems) and restrictions on the interpretation of the meaning of concepts (terms) are de ned. For example, for the diagnosis of processes, one of the most common types of sentences (statements) is < deviation class k , characteristic j , range of values kj of characteristic j >; sentences like "a necessary condition for the existence of the process", "a variant of the process of changing the values of the attribute", etc.).
The knowledge base contains domain knowledge that is presented explicitly. They are generated manually or inductively, including from training samples from archives and databases (inductive generalization in machine learning (Finn 2014), Bayesian classi ers, clustering algorithms, and reinforced learning (Nikolenko and Tulupiev 2009;Golenkov et al. 2018)).
The base of facts contains a set of facts (statements) observed or objectively measured in the situation under consideration, regarding which the problem is being solved.
The explicit representation (and grouping) in the ontology of all structural types of statements (and the separation of the ontology from the knowledge base) necessitates the "replacement" of decision-makers, interpreting production rules, with specialized ontology-based algorithms.
An ontological-oriented algorithm (ontological reasoner) searches for or refutes hypotheses bypassing the (declarative) knowledge base. Such an ontology-oriented problem solver "sorting through" the KB statements of each type related to the hypothesis. He compares these sentences of input information (about the object). The algorithm for bypassing the knowledge base and comparing its statements with the elements of the structure of domain objects is generally simple, because the number of "matching rules" is determined by the types of KB statements corresponding to the problem being solved.
The implementation of the bypassing the declarative knowledge base mainly consists in searching for the values of input data in the knowledge base. (Example: the implementation of the bypassing the declarative Diagnostic Knowledge Base usually consists in searching for the values of the signs (symptoms) of the diagnosed object and comparing them with the areas of (expected) values in order to reject or con rm the corresponding hypotheses about the classes of deviations). Thus, the "structural" complexity of an ontology-oriented algorithm is usually small. Its complexity is determined by: • The number and complexity of the types of axioms (statements) of the ontology, • The length of the chains of cause-effect relations between the hypotheses and observations -the elements of the description of the domain objects, • The number of observations (description elements) of the objects and/or the number of restrictions / target conditions, for example, in the designing problem, the conditions will relate to the sizes and different properties of the constructed object (bridge, hardware complex, ...); in the treatment task restriction is "the object must become healthy"). The processing time (calculation) depends on the size of the knowledge base.
Such solvers can become reusable, because, rstly, a set of traditionally solved problems (diagnostics, forecasting, control, designing, planning ...) is known (Clancey 1985;Kleschev and Shalfeeva 2015), and secondly, a traditional set of types of relationships in domains with cause-effect relations (for solving the problems of diagnostics, forecasting, and object state control) (Clancey 1985 Using an ontology to form a knowledge base, data (facts), as well as an explanation structure makes it possible to generate a user interface (GUI) in terms (concepts) that are understandable to a specialist, and also, as a rule, generate a dialogue scenario corresponding to the structure of explaining the results.
KBSs as a variety of software can also: • Include databases for storing reference or other information, • Accept les or databases with operational information (about the situation regarding which a decision is required), • Create as a result les or databases with the results of the work and an explanation of solution.
Thus, viable system of explainable AI should include: knowledge base described in terms of ontology, ontology-based solver (it can to put forward and explain hypotheses), ontology-dependent adaptive and adaptable user interface. It is high-level architectural design model of KBS.
The most characteristic properties of KBSs related to viability are: • Regular updating of knowledge base; • The admissibility of the improvement of the decision-making method; • The permissibility of changing or adding functions (for example, the formation of additional results); • Adaptability of the user interface due to changes in the input data; • The permissibility of expanding the ontology (adding concepts, relationships).
Changes in the ontology, as a rule, lead to the adjustment of all components of KBSs; in this case, it is advisable to talk about a new version of the KBS.
As a result, the structure of KBS and its components does not require changes due to the current maintenance and sustainable development (Chhabra 2017).

Ontological approach to support and evolving of KBSs
Ontology more often corresponds to one class of problems being solved or to one class of problems in one subject area. To design applied KBSs, not one ontology may be required, but their set of ones for interconnected problems. The examples of related problems are diagnosing and x-planning or predicting.
A toolkit for constructing application systems with declarative knowledge is based on the ontology of the subject area, since algorithms process information from subject area. An formalized information being processed in their algorithms is a laws of the subject area, a real facts, an archived data and documents stored.
Knowledge and other information should be formed in terms of uni ed terminological concepts of subject area and in accordance with the structure determined by ontology of domain -ontology of knowledge and of reality's data. Ontological agreements on the rules of matching facts to knowledge should be known to developers of algorithms for solving problems.
Let's call the toolkit that allows create KBS components on base of domain ontology the specialized development environment for KBSs.
A specialized environment for manufacturing and development of knowledge-based systems should at least provide: • KB Editor, • Database Editor, • Editor of solution results' explanations structure, • A library of reusable software solvers corresponding to the classes of tasks to be solved • A library of software units (the components of software solvers), • Search and selection tools for KBS components -KBs and software solvers, • Tools for integration of knowledge bases and solvers, • Specialized UI editor.

Note
In a situation where the possibility of making changes to domain ontology is not ruled out even after building knowledge bases, manufacturing environment of KBSs should provide an ontology editing tool.
The introduction of additional concepts or new relationships between concepts in the ontology does not violate operability of AI software solvers. The ontology-oriented solver has this property because it processes only concrete types of sentences from Knowledge Base.
To form the solvers you will need:

Note
The ability to create program units for the solver may turn out to be unnecessary if the ready-made solver is according with the statement of the problem, and "building up" additional functionality is not supposed.
The complete architecture framework of knowledge based system is < set of KBs, set of software solvers, set of UI-components, set of factBases, set of software units>.
Due to the importance of developing and evolving knowledge bases, only those KBSs that are integrated with knowledge base management system (KBMS) should be seriously considered. So the software components for evolving and checking of knowledge bases are desirable to be the part of the "integrated architecture". Then the manufacturing environment has to provide: • Tools of checking and assessing of knowledge bases, • Tools of evaluating quality of knowledge bases by archives of solved problems, • Tools of inductive formation of knowledge bases or fragments of knowledge bases.
KBS acquire the aforementioned vitality properties with these KBMS tools from specialized environment for its development.
The property 1 -support for updating knowledge.
The property 2 -support for changing con guration of an ontology-oriented solver (in connection with the replacement of a component that implements a different decision strategy or method of obtaining the result, or in connection with the addition of a component that implements an additional function, for example, generating an additional result).
The property 3 -Support for improving the UI in connection with a change in functions.
The property 4 -support for change in ontology.
The property 5 -support for improving UI of the expert (and UI of the user) in connection with updating the ontology.
The property 6 -support for coding new versions of software units of an ontology-oriented solver or support for solver code changes. The example of changes is adaptation of algorithm of processing Knowledge Base in connection with updating an ontology of knowledge.

An example of the implementation of KBSs manufacturing environments
The example of tools for creating environments for manufacturing of KBSs is the instruments implemented on the IACPaaS platform for processing ontological information resources (such resources are being generated in terms of an explicitly presented ontology or "meta-information") (Gribova et al. 2018). The ontology de nes the rules for forming information, and the limitations of its interpretation.
The structure of the information generated and a number of interpretation restrictions are determined by the users of the IACPaaS platform for their own information resources formation. Usually a cognitologist makes this work for the community of experts, specialists, and users.
KBSs is a special case of applicated software services on the IACPaaS platform (IACPaaS services) (Fig.   1).
This toolkit also contains tools for managing software components of KBSs (Fig. 2): • "Master" of the formation of declarative parts of SUs (IACPaaS agents), • Solver constructor from the root IACPaaS agent and processing agents (they are being represented only by declarative part), • Generator of code workpieces (blanks) for new IACPaaS agents (or new versions), • Byte code loader integrated with declarative part of agent, • Tools for testing SU and preparing them for the library of SUs (agents).

Page 13/29
The set of tools for formation of KBS' information components is as follows: • IACPaaS ontology editor (Fig. 3a), • IACPaaS-editor of knowledge base, generated in terms of ontology with a self-adaptive UI (when changing an ontology) (Fig. 3b), • IACPaaS Data Base Editor (with self-adaptive UIs) (Fig. 3c).
This toolkit also contains tools for managing software components of KBSs: • "Master" of the formation of declarative parts of SUs (IACPaaS agents), • Solver constructor from the root IACPaaS agent and processing agents (they are being represented only by declarative part), • Generator of code workpieces (blanks) for new IACPaaS agents (or new versions), • Byte code loader integrated with declarative part of agent, • Tools for testing SU and preparing them for the library of SUs (agents).
IACPaaS agents are encoded in Java. The Java Development Kit (JDK) for Java SE 8, 9, … 13 is recommended for writing source codes and creating agent byte codeThe environment for KBS manufacturing implies coding of new versions of agents (when it is necessary to process new terms or new relations of terms) or coding of new IACPaaS agents (when it is necessary to make a change in the decision-making process). JDK can be local to the programmer (or hosted on the IACPaaS platform).

Note
On the IACPaaS platform, the "master" of formation declarative parts of solver and SU are both the Editors generated in terms of corresponding meta-information. This meta-information is the part of ontology of the IACPaaS technology. A self-adaptive UI for forming data and knowledge and for viewing the results of KBSs provides three visualization views, one of which is graphical.
Thus, the manufacturing of KBSs using ontology-oriented environments fundamentally increases their viability by signi cantly increasing the role and share of controls (for making changes to declarative components) vs. coding and factoring tools (for making changes to the source code).
The KBS design technology in the proposed environment provides for a sequence of activities.
1. Create a problem ontology or search for ready-made ontologies of knowledge base about a particular task and data ontologies. If the IACPaaS platform does not yet have a portal for the problem under consideration, then the knowledge engineer uses the Ontology editor to create a resource "Knowledge ontology" -a description of a set of concepts, relationships, and restrictions used by specialists when solving problems (and / or when transferring knowledge between specialists). It should be su cient to provide all the necessary knowledge about the decision process. One of the most important works is the formation of the domain thesaurus (names of objects, their attributes, and possible values for each attribute or ranges of values). Often, an engineer, together with an expert, xes a set of rules for making decisions, called "agreements".
2. Formation of the knowledge base by the domain experts. It is important to note that the IACPaaS platform has a Knowledge Base Editor Generator that automatically generates expert-oriented editors based on the knowledge ontology. As a rule, the creation of KB is a collective process.. 3. Designers and programmers create new software components (if a portal with an already created solver is not found on the IACPaaS platform). To do this, the designer uses the Ontology editor to create an Ontology of explanation (the result of KBS's work must be an explanation). Next, the solver components (agents) are declared and implemented using software engineering methods.

Note
Creating the solver and knowledge bases are parallel processes. Some library may already contain a set of solvers or program units (agents) for the problem to be solved. Then creating a solver is not required. The main work is reduced to the formation of new knowledge. The ontological framework ensures the compatibility of components within the formed portals.

Ensuring Kbss Viability With Iacpaas Environment Tools
The above-described characteristic properties of KBSs related to viability are provided in development environments implemented on the IACPaaS platform. Consider this with the example of the Knowledge Updatability property and the support for updating knowledge.
If updating the knowledge base is required in connection with obtaining new knowledge (statements), it is natural to modify them manually (and evaluate the consistency with the available facts). For this process (in the development environment) Editors are required for all knowledge bases.
On the IACPaaS platform, the regular generator of Infomation Resource Editors is always operating, therefore knowledge base editors are always available in manufacturing environment. Currently a tool for checking the quality of the new version of the knowledge base vs. last (or current) one under development. It must check non-decrease of set of correctly solving tasks when replacing the version of the knowledge base (according to the importance of monotonous improvement of knowledge bases (Kleschev et al. 2013)). The procedure of checking of non-deterioration of knowledge is: to enter the input conditions of reference task to the solver, integrated with the new version of the knowledge base, to obtain the result (explanation) and to compare the obtained explanation with the output of this reference task.
If you need to update the knowledge base in connection with obtaining "facts" (precedents, decisions) that are not consistent with knowledge (when the precedent contains the correct result of solving the problem, which does not correspond to the result obtained using KBSs), then it is effective to form a new version of the KB automatically (by inductive methods). The example of such an update of knowledge "from practice" is: after a certain period of time, the correct result of diagnosis or treatment "comes" (from a medical institution), it is compared with the result from KBS: are they contradictory. Then it is preferably to evaluate the consistency of work result of updated KBSs with existing precedents.
So, to implement the process of monotonous improvement of knowledge bases (based on the methods of inductive formation of knowledge base fragments (Kleschev 2013)), the following means are required: • Tools of inductive knowledge formation for each solved intellectual problem (diagnostics, planning, forecasting ...); • Tools of supporting the choice of precedents (correctly solved problems in one statement); • Tools of verifying the correctness (quality) of the new version of the KB (the same as described above).
The checking of the "Knowledge Updatability" property is to check the availability and performance of the above tools. There is always a regular (self-adaptive) Editor on the IACPaaS platform; other tools are added to the development environment one after another.
We compared the process of building a complex of interconnected developing knowledge bases to build a medical decision support system for the diagnosis and treatment of diseases using the Protege (Musen 2015) and IACPaaS tools (Gribova et al. 2019). For this purpose, we have created classi ers of diseases, symptoms and medicines on the Protege platform. Next, using the Object Property mechanism, we needed to link diseases with symptoms (some acute diseases required a dynamic description of the clinical picture). However, these mechanisms did not provide an opportunity to describe knowledge in a form that is required and understandable to doctors, and the description of the dynamics of the development of diseases was particularly di cult. It should be noted that the Protege tools are incomprehensible and di cult for doctors, they are intended for knowledge engineers (although the description of the dynamics for them turned out to be di cult work). Similar di culties were caused by attempts to describe treatment protocols taking into account the speci cs of the use of medicines and the characteristics of patients. Protege's mechanisms did not allow the patient's history to be formed as a single document. In a network of such relations experts then began to create knowledge bases without the participation of knowledge engineers. To date, doctors have created and maintained knowledge bases on a wide range of nosologies (see Fig. 4). The total number of vertices in the knowledge bases is more than 100,000.

Using Iacpaas Environment Tools To Create Viable Kbs
The toolkit is already being used for collaborative development of cloud-based thematic Knowledge Portals and viable KBS. The domains are technical diagnostics of autonomous underwater vehicles Then development of knowledge bases and intelligent software components for viable intelligent medical software services began in parallel. Such services are intended to automate medical teams and institutions through the provision of "cloud" tools for support all the tasks of intellectual activity solved there.
Often, such "labour unit" has more than one activity pro le (m pro les) and solves several intellectual problems (diagnostics, treatment, prognosis). The "cloud" implementation of KBSs makes it possible to use a single knowledge base for several classes of tasks and pro les. General knowledge bases accumulate in addition to universal knowledge the experience of several professional communities and teams.
Knowledge bases were created on various nosologies: viral, diseases of oral cavity, salivary glands and jaws; diseases of the gallbladder, biliary tract and pancreas; bowel disease; hemorrhagic fevers; coronary heart disease; diseases characterized by increased blood pressure; chronic rheumatic heart disease. Specialists in mucopolysaccharidoses formed knowledge, tested them on real examples of patients from different countries, and proceeded to re ne knowledge. Usually, experts form a clinical picture of diseases with dozens of dynamic symptoms (Fig. 5).
Ontology-based solvers are reusable components of KBSs. They were integrated with different knowledge bases of a wide or, on the contrary, narrow spectrum in order to provide a multitude of software services for supporting solutions for different categories of users. The standard service assembly assumes a standard GUI. Then a specialized, improved GUI is created, being customized to such set of terms from a glossary of terms to which specialists of their pro le are limited.
The assembly of services from the knowledge base and the corresponding solvers was carried out and is carried out at workplaces depending on the needs of specialists. Users get access to the necessary services in their Personal o ce areas on a cloud platform. This allows them to accumulate archives of case records for each pro le on the cloud server during operation (for next training, for veri cation). The "cloud" implementation of KBS allows use common solvers and common knowledge base control system.
The development and implementation process showed that the labor costs for automation of all user teams (for m activity pro les in each) are close to the costs for automation of one institution: the volume of work is performed in one "place" (instead of performing it at each workplace). For m activity pro les, n * m knowledge bases (and their management systems) are required. There is no need for each institution to speci cally engage in the improvement of knowledge (enough designate responsible persons).
Today specialists from various medical elds use the portal tools to develop formalized knowledge and its use. KB is large and maintained by a large number of specialists. To update current diagnostic knowledge, tools for search precedents, tools for editing knowledge bases, and tools for it checking are used. Update activities are carried out in accordance with procedures that allow users services themselves to remain operational. So, knowledge about some diseases of the digestive system was expanded, knowledge about region-speci c manifestations of fever caused by rodents was clari ed, and new unique knowledge about mucopolysaccharidoses was added. And neurology specialists formed the terminological base of symptoms for digitizing existing archives, for preparing them for the inductive generation of knowledge about neurology diagnosis, treatment, and prognosis of recovery.
A comparative analysis of labor costs (number of employees) to maintain the relevance of the KBS is carried out: in the case of cloud-based implementation of the KBS with the separation of competencies and in the traditional development of the KBS.
Let N conditional medical institutions working on P medical pro les with M = 3 tasks (and K development teams involved in automation, presumably working on different technologies). The diagram below ( Fig. 6) shows the estimated number of specialists (vertically) involved in the development (maintenance of relevance and improvement) of the KBS in the traditional approach, the lower level shows the situation in the cloud implementation of the KBS with the separation of competencies. In horizontal direction, some principal stages and results of work performed by different categories of participants are presented. It is shown that in the new KBS cloud technology with the division of competencies, P * 2 specialists will be required to improve the diagnostic knowledge base (compared to N * P -with the traditional approach). Similarly, improving the knowledge base about treatment (P * 2 pers.) Vs. (N * P); improving Diagnostic Solver With Interface − 2 People Vs. K * P persons.
Another case (experiment) of checking the system (viability model) was in early 2020 a request to expand the service for the diagnosis and treatment of viral diseases with the possibility of differentiating diseases caused by COVID-19 among many respiratory diseases (Fig. 5).
In comparison with other service providers who presented updated versions a few months after the appearance of diagnostic guidelines (Infermedica, klinica.com.ua, medicase.pro), in our technology, the addition to existing knowledge base by description of several known variants of manifestation and course and diagnosing methods of new disease took several days. So a week later, a new demanded cloud service was deployed to search for hypotheses about a patient's possible viral disease and differential diagnostics.
The Service is an example of explanatory AI. It provides a rationale for the proposed solutions and the recommendations issued (as opposed to klinica.com.ua, medicase.pro). The service informs which signs of the disease are / are not included in the clinical picture of the diseases in question, and also, whether additional information is needed to con rm or refute. At the same time the service prompts which values of which signs need to be obtained additionally.
The new cloud service and a declarative way to get it (based on the existing solver) demonstrate: feasibility of the method and approach to evolving of KBSs, the adequacy of the proposed infrastructure for manufacturing of KBSs and support their evolving.
Thus, the use of the proposed approach ensured the construction of multi-user medical software services to support the decisions made by specialists in different pro les based on knowledge remotely supported by experts.

Conclusion
Through cloud-platform family of tools, the proposed ontology-oriented manufacturing method has been demonstrated to provide an effective means to produce knowledge-based products family and achieving scalability, viability and adequacy to professional level of users. The contribution of this paper is presented in ve aspects.
1. The proposed approach implements explicit separation between main KBS components: knowledge base and problem solver with user interface, That is, a very important requirement of software engineering is implemented, which provides the possibility of independent (but consistent) creation and maintenance of each architectural component. So, in the proposed approach, domain knowledge is concentrated in the knowledge base (including various types of causal, spatial, and temporal knowledge), the solver does not contain domain knowledge. Recall that this requirement could not be implemented either in the production model or in object-oriented ontological models of knowledge. In them, some of the knowledge is included in the problem solver, which means that when you change the knowledge, you need to change both the knowledge base and the solver.
2. Explicit separation between the ontology and the knowledge base. In other systems based on the ontological approach, the issue of a clear division between ontology and knowledge has not yet been resolved, as a result, the division of competencies between specialists who create an ontology and specialists who create a knowledge base is quite di cult to implement. We rely on the fact that the activity of creating an ontology is signi cantly different from the activity of creating a knowledge base.
Creating an ontology is a creative process that requires a lot of analytical work, a systematic analysis of the domain area in order to identify common patterns in the formation of knowledge, its structure, and integrity constraints. This activity should be carried out by cognitive scientists (knowledge engineers) together with experts. When creating an ontology, it is important to create it in such a way that it "covers" a class of tasks (for example, an ontology of knowledge on the diagnosis of diseases regardless of their etiology [42], an ontology of knowledge on the modes of laser additive manufacturing [43]. The ontology is generally not changeable throughout the KBS lifecycle. The knowledge base is an ever-changing component. It should be formed and modi ed by experts of the domain independently (without cognitive scientists and knowledge engineers) based on the created ontology (it is mandatory to have knowledge editors controlled by the ontology).
3. Tools for estimating the created knowledge base. We believe that this is a very important requirement of software engineering. We automatically evaluate the formal completeness of the knowledge base, a number of integrity and correctness constraints (based on the ontology). In addition, an important requirement is the availability of tools for estimating the knowledge base at any change using the accumulated cases (precedents). This ensures a monotonous improvement of the knowledge base, we can always argue on which base of cases the created knowledge base works correctly. 4. Generating detailed explanations is a very important element of KBS. In our approach, the explanation is generated based on the explanation ontology, which is built using the knowledge base ontology (in some cases, it partially repeats its structure). Having explanations is also useful when debugging the knowledge base. 5. The ontological solver, together with the user interface, is repeatedly used for a variety of systems with knowledge bases. It does not depend on the content of knowledge bases (it uses a knowledge base as a parameter), so their completeness and quality can be improved in nitely by integrating with the solver into new and different versions of useful systems.
Unlike most existing methods of knowledge-based product constructing, that assume either presence of a su cient set of data to extract the necessary knowledge from them, or the presence of an expert who is able to formulate a su cient set of knowledge, our research attempts to address the problem across the compatibility and complementarity of these paths, rather than interchangeability, including providing an explanation of the generated solutions.
The method was tested for su ciently computational e ciency for a large-scale knowledge-based products family design problem. The presented cost model can provide insight on what can be achieved from building cloud systems from shared or reused ontological solvers and being evolved bases.
The current research work focused on an emerging concept in KBSs Manufacturing and their controlled improvement.
The goal of this study was to provide a manufacturing environment for producting viable systems.
The proposed methodology proved to be easy to learn and convenient for teamwork.
For a medical diagnostic system, each signi cant expansion of knowledge (more than 20 such acts were performed in total) required from 5 hours to 2 working days for an expert, 2-3 hours for quality control, 10 minutes for architector, and without programmer, which in another production environment would be unattainable.
The results from the analysis of product characteristics after each update showed that the results were consistent with case-samples received from real practice.
The exibility of the proposed methodology and tool can also be a bene t in cases where a quick recon guration of the production is required to adapt to new circumstances, as was required to recognize COVID-19 in patients. A limitation of the current approach is that the solver is explanation content-speci c (depends on the speci c composition of the generated explanation): if the degree of detail changes, the software components that record the explanation must be modi ed.
Further research steps should focus mainly on the integration of the developed tools with textual facts and knowledge parsers and with third-party diagnostic and predictive tools.
A detailed study is required to demonstrate whether the components working with structured information, with verbal text, with images and digital arrays, can be combined into a single complex.
This approach would save valuable time users from critical areas of activity.
Work is currently underway to further expand the capabilities of the approach. Today, the «bottleneck» for us is an adaptable user interface. The technology allows you to generate three types of user interfaces based on the explanation ontology, but these features are not enough. We are currently working on creating tools for automatically generating an interface based on the user model, taking into account the requirements of usability.