Thursday, November 8, 2018

Self-adjusted AI Robot

The AI system couldn’t learn as human being, but developers could make it self-adjusted based on a set of live data and measurement.

There are many robots used in manufacturing plants, e.g. auto parts, paper clip, binders, etc. Those robots were pre-programmed to create a product according to its specification.

The issue was robot could be out of sync or miss calibration over time of use. The developers could estimate or predict the out of calibration cases and use sensors to measure real time products in order to adjust the robot automatically.

One of the issue was the conveyor belt is limited in length. The robots made parts and dropped it on the conveyor belt, which run at determined speed. Some parts had more minor defects then others, thus time required to fix it longer. For example, auto parts made by robots had something called “gates or flashes”, which required operator to trim it manually with a knife or a cutter. If a part had more gates or flashes, operators would need more time to trim those. However the robot didn’t slow down, thus many parts would be lined up on the conveyors belt. The robot may be halted in this case, and time to restart a robot is long; the products right after starting robot is not good, i.e. wasted materials.  The robot should be equipped with a sensor or camera to monitor parts on the conveyor belt. It should slow down if there were many parts on it.

There are many cases, developers could implement a system equipped with sensors, camera, or laser beam to monitor a situation and re-calibrate the robot according to live data and measurement. For example, if a part is longer than specification, it could adjust the robot to make next part correctly in length.

Wednesday, October 24, 2018

Artificial Intelligence

Artificial Intelligence (AI) has a critical limit, i.e. its ability to learn new behaviors, because a computer cannot think as human. Computer can only perform what developers told or taught it to do.

Human could base on facts/data to analyze and come up with decision or new algorithms.

The best AI system would be like an expert system with huge database of data. Developers could write algorithms or systems to analyze new data based on prestored data and its associated behaviors.

New (missing) set of data or facts would be entered in systems associated with a new behavior.

If you said that an AI system could generate new codes and behaviors, it only means this AI system generated codes based what developers thought and had written codes in the system.

Imagine if an AI system could think and learn, we could put an AI system equipped with a microphone, camera, and speaker in class rooms from grade 1 to a Ph.D. class, and then we could get a PhD AI system. However, and the AI system or a computer couldn’t learn anything, so it didn’t work.

Tuesday, October 23, 2018

Machine learning with data driven

Machine learning with data driven method

After watching a video interview with Ericsson CTO, he mentioned that the machine learning is data driven. I think, the following model is applicable for a weather forecast. Operator would enter new data about an unknown weather condition, so the computer learnt and it would be able to forecast correctly next time if it happened again.
For example, a weather condition is based on atmosphere pressure, cloud movement, wind movement, temperature, etc. Thus system would have those data stored in database for each case or weather condition. Based on collected data, system could forecast rain, snow fall, etc.
This model could be used for other cases to build an expert system with known data and facts, so the system could predict those cases based on collected data. Operator would teach or enter new (missing) facts and data, so the system could predict those in the future correctly.

Tuesday, September 18, 2018

AI Censor Engine

The dynamic encryption process described in other notes would require high processing power of user’s computer. Most of our computers are equipped with a single microprocessor, thus it may not powerful enough to crunch data, i.e. encrypt and decrypt messages.

Let’s make encryption tasks simpler for single microprocessor computer such as Windows 10, i.e. using AI Censor Engine.
The encryption of outgoing packets could be based on selected keywords stored in database, e.g. secret, classified, personal, confidential, etc. This way would also require the computer to open outgoing packets and check for selected keywords in order to perform encryption. This method also demands significant processing power.

The easiest way, computer could encrypt a few packets randomly in a bundle or set of outgoing packets, e.g. 2 packets out of 10 outgoing packets. This is like blacking out a few phrases or sentences.

Tuesday, September 11, 2018

Adding a field in a table without interrupting live traffic


Figure 1. Structure of data in a database table

Assuming that data fields (columns) in a table are stored using linked list in a hard drive, the last pointer is usually set to “null” to end a linked list.

Let’s say the original table has 2 fields at first. Users wanted to add the third field without interrupting traffic. The second field would point to a pointer with value “null”.

If the database engine is structured left to right, i.e. the first column would be indexed as 1, and second field indexed as 2. During a search, update, or delete a field the correct index is used. Indexing could be done by a compiler to compile an application program and translate those fields into database’s table indices.

So, when a user adds another field, the database engine would modify the original “null” pointer at the first construction to point to another field in the hard drive, i.e. connecting the second field to the third field. Of course, the third field would point to the “null” pointer again. This scenario is useful when doing live upgrading on the executive node with new data field introduced for additional software.

The index of the “pointer to third field” is not counted.

Removing a field is complicated because the database structure has changed. Doing so may cause corrupting data during live traffic due to incorrect indices.

The process to remove a second data field is described in figure 1 by updating the pointer and its index.

Live upgrade on executive node

This is a special case for system providers. If a system provider has come up with a system with all features developed and could load assembly codes on a live system such as APY.

The system provider could preconfigure database with all fields, tables and clear protocols between subsystems. Each subsystem is a feature communicating with other systems using a predefined dispatching protocol interface.
System provider can deploy a full database with tables and fields. If customers didn’t want a feature, the corresponding tables and fields would be empty. That subsystem’s codes would not be loaded.

If customer bought a feature at later date, system providers only need to populate those database fields, database tables, and load assembly codes of that subsystem on the executive node. After that they only need to activate the subsystem by a command.

Live upgrade with data transferring


Figure 1. Data and software upgrades


A. Data upgrade process
As shown in figure 1, the executive server and mirror server are receiving live data during a software upgrade with data transferring from the executive server to the mirror side in parallel.
The process could be described as follows:
1. Disconnect the mirror side from live traffic
2. Load new software or data on the mirror server
3. Start upgrading by allowing data with its timestamp from the executive server transferring to the mirror side in parallel with live data coming to the mirror server at the same time.
- The executive server keeps offering services to users during data upgrade
- Data coming from live traffic to the mirror server would have higher priority as compared to data updates with timestamp coming from the executive server, i.e. live data would be written to the mirror database if data collision occurred.
The process of data update is carried out orderly in the executive server while live data coming from the users randomly or unpredictably.
After data transferring from the executive server to the mirror sever completed, operators would run a command (or automatically by system) to switch the mirror server to executive side. Software and data would be transferred from the new executive server to the new mirror server. Both sides would be operated normally after software and data completely upgraded.

B. Exception

There is a case that life traffic data to mirror server are not completed or incorrect, because those are dynamic data.

For example, user is making a call and that call couldn’t be properly setup in the upgraded mirror server, because there was no physical connection of phones. However, data was properly written on the executive side. If those data fields had been transferred to the mirror server during data update with timestamp, the mirror server missed some live data.

In order to save some dynamic data, the software upgrade process could record data fields newly written that have created or written on the executive server, but those haven’t written in the mirror server. This is the second pass of data transfer. The executive server transfers those data to the mirror server.

Because live traffic is ongoing forever, the upgrade process must stop after the second pass or third pass. We must accept some data lost.

C. Additional pass of data transfer

The operating system could perform another loop of screening data to be transferred between the executive server and the mirror server. If data in the executive server is newer based on the timestamp, data would be copied to the mirror server again.

However, this is not a bullet proof method as data keep updating and the screening loop and data copy takes some time.

I heard that IBM and Ericsson came up with a better strategy to transfer missing data by the operating system in parallel. I think, this should be a better method.

Thursday, September 6, 2018

Dispatching requests for server’s access


Figure 1. Diagram of settings to dispatching requests for server’s access
Currently there are talking about cloud servers, which locations of servers are unknown. One of those configurations would be block chain servers.

How could you offer a service to clients without knowledge of your servers such as encryption technology, admin personnel, and locations of those servers? If there was something wrong, how could you fix that or identify the problems?
Block chain’s service should be ruled out by governments as detectives couldn’t localize, locate, or identify any source of problems.

In the diagram above, it describes an example of configuration of Dispatching Interface Gateway for Google’s services.
Let assume that Canada and USA requires gmail server for their residents must be located in their soil. Any request access for gmail would be redirected to correct servers in either Canada or USA by the Dispatching Interface Gateway.

With this configuration, we could tap or monitor the Dispatching Interface Gateway to follow an access request in case of problems.