Next Generation Autonomous Control - Dynamic Artificial Intelligence DAI

 Real-time autonomous control for distributed and edge devices using a hybrid of real-time Neural Networks, Inference Engines, and Evolutionary Computational Structures.

Abstract

Dynamic Artificial Intelligence (DAI™) is a new technology originated by Xtensor Systems to develop and integrate next-generation autonomous systems. DAI™ enables real-time control of distributed edge devices, remote locations, and distributed equipment without the need for a centralized control system or cloud data sets. DAI™ creates secure Autonomous applications that respond dynamically to changing local conditions. The system provides Autonomy by switching from one neural net or inference engine configuration to another in real-time.

What is Autonomous Control?

Autonomous control solutions include products, systems, and services that respond autonomously with specific actions without human interaction. In general, they are a combination of proprietary automation, control, sensing, and AI technologies. The technology utilization is still early-stage with initial applications including military vehicles (land/sea/undersea/air) and commercial vertical solutions (automobile, robotics, and more). Autonomy promises to create better, faster, and cheaper commercial solutions.

What is Missing from Current Autonomous Solutions?

Before Autonomous solutions can takeoff commercially, several issues need resolution:

Scalability

AI requires expertise to design and build integrated solutions

AI Complexity

Limited AI expertise in the market – early-stage market

Real-time Capabilities

Edge solutions require local real-time response

Distributed Functionality

Complex integration when distributing functionality

Security

Data, communications, and cybersecurity vulnerabilities

Long Lead Times

Long lead times until solutions are fully functional

Adds, Moves, Changes

Variability requires constant solution modifications

What is Dynamic Artificial Intelligence

Dynamic Artificial Intelligence™ (DAI™) is Xtensor’s patented autonomous control software that powers the next generation of secure, highly intelligent Edge devices, products, systems, and services. It is a complementary technology designed to integrate control solutions with management solutions more quickly. DAI™ technology brings high-performance and high scalability to distributed applications without producing heavy network traffic. DAI™ pre-optimizes system processes with minimal human intervention. DAI™ can be reconfigured, updated, and upgraded remotely for servicing and support. DAI™ proactively responds to problems and threats in 10 milliseconds. Complex Edge challenges can be resolved automatically in less than one second instead of hours or days using existing solutions.

Why DAI™?

DAI™ introduces new Autonomous capabilities into the changing control and management markets. DAI™ is a flexible platform that can migrate existing solutions into the future. It can help transform existing products, systems, and services into leading-edge, fully Autonomous solutions.

DAI Features and Benefits

DAI™ Next-generation Autonomous Control Software provides the following advantages: Autonomous optimization

Fast setup, improved support, optimized field service

Autonomous reconfiguration

Faster local response and problem resolution

Rapid customization

Meet exact local needs, maximize uptime

System-wide encryption

System-wide end-to-end security

Stealth mode operations

Secure operations and system management

Easy 3rd party integration

Fast time-to-market, cost-effective solution

Automated 24/7 operations

Fast payback, improved customer satisfaction

What makes DAI™ New?

DAI™ provides 24/7 autonomous solutions, including:

End-to-end security

Secure encrypted data and end-to-end communications

Simple API

Solutions delivered faster, reduced staffing requirements

Distributed edge solutions

Proactive edge devices and services

Solution flexibility

Proactive distributed control

Scalable solutions

Encrypted global 24/7 solutions

Cost-effectiveness

Cost-effective heterogeneous environment integration

Predictive abilities

Proactive problem detection

Easy localization

User interface localized to local requirements

How will DAI™ help you?

For example, DAI can help you develop and integrate the following types of Autonomous solutions:

· Upgrade existing process control solutions to proactive AI-enabled systems

· Integrate remote site management

· Implement complex automation to mimic human expertise

· Implement 24/7 global autonomous management solutions

· Integrate control closet equipment management into network management

· Integrate remote equipment management with control solutions

· Integrate physical security into network management

· Autonomous operations without network connections and in intermittent environments

· Integrate control solutions with management solutions

· Integrate heterogeneous equipment management with management solutions

· Integrate edge equipment management with management solutions

· Integrate edge solutions into network management solutions

Conclusion:

DAI™ introduces new Autonomous capabilities into the changing control markets. DAI™ is a flexible platform that can help you migrate your existing solutions into the future. Xtensor Systems is looking for partners who want to realize a better future. To succeed, we want to work with you to solve big problems. We are looking for good long-term projects and technical input from industry leaders and visionaries who want to create next-gen Autonomous solutions sooner rather than later. We can help transform existing products, systems, and services into leading-edge, fully Autonomous solutions.

Written by John Lenko, CEO of Xtensor Systems. Xtensor is working on leading-edge autonomy solutions with PhDs from NASA, Jet Propulsion Laboratory, the Autonomy Research Center (Cal State Northridge), and more. As a result, Xtensor has developed a fast, easy, and low-cost way to build next-gen autonomous solutions. These systems run, correct, and adjust themselves without needing an army of subject matter experts.

Mr. Lenko has extensive software, hardware, network management, local area network, wide area network, and service industry expertise. His work includes industry-first products and services for Spirent Communications (Netcom Systems), Network General Corporation, and British Telecom. He specializes in developing new products and markets and growing start-up opportunities into highly profitable businesses.

Mr. Lenko received his Undergraduate degree in Marketing from Santa Clara University and an MBA from the Wharton School of Business.

Xtensor Systems provides an integrated development, simulation, testing, and deployment platform for next-gen fully autonomous solutions. Our customers include researchers developing Autonomous next-gen technologies, HW/SW developers developing fully Autonomous solutions, vendors trying to integrate Autonomy into their distributed infrastructure solutions, and vendors needing real-time process control.

Our partners include heavy technical experience in (1) autonomous robotics, (2) computer vision, (3) aerial platform navigation, (4) artificial intelligence, (5) embedded systems, (6) software development, and (7) unmanned aircraft integration.

Xtensor contact email: info@xtensor.com

Xtensor web site: www.xtensor.com

When Is A Lost Packet Not Lost?

 I was working with a customer and started explaining the concept of what I affectionately refer to as, “application baselining”. I asked my client to pick an application to test and he chose his favorite network monitoring application.

I then explained the concepts of an “application baseline”. For those of you who may not be familiar with the term, an application baseline (or snapshot) is a process where you document the behavior of an application. An example of items that would be of interest are:

• IP addresses the application communicates to

• Function of those IP addresses (i.e. DNS, DHCP, Web server, etc)

• Amount of data transferred

• Protocols used

• Other observations such as clear text data, proprietary application notes

• Application behavior when errors or timeouts are encountered.

I asked him to put my laptop’s ip address into the monitoring application. We then captured the pings from the management server and noticed some cool things. For example, all the pings had a 99 byte payload with a specific string in the payload. We also noticed that it was using ipv6 as well as ipv4 and IPX. Yes folks I said IPX. I suggested we disable the unnecessary protocols (IPX and IPV6) as an exercise in reducing extra multicasts and broadcasts, and then verified that the protocols were actually disabled by taking another trace. I also noticed that RIP was enabled and we turned that off as well.

My client then commented, “When you get the hang of it, this really isn’t a big deal.” I love it when I believe that someone really gets it. He went on to explain that he thought a baseline took days, if not weeks to complete and at the end you would end up with binders of information that no one reads. Man, did he ever hit that myth on the head. Not true!!

As I mentioned earlier, a baseline is just another word for a snapshot. That snapshot can be basically anything, a login, a boot up, a query. As long as you document how you did it, it is correct. The snapshot can be a simple paragraph, a page or several pages of observations and findings. I prefer to take many simple specific snapshots since they can be gathered quickly. If they are related, then it is easy to combine them. The bonus is that they are easy to compare when you have an upgrade or reported problem. For example, if you have a snapshot of a user performing an account query and it took 10 seconds, you could easily compare it to the same query when it is reported that it now takes 60 seconds. The only thing you have to be careful about is server handoffs or multi-tiered applications behind the scenes.

In those cases you need to capture from the backend as well to get a complete picture.

Lets get back to our network monitoring application baseline. I simply powered off my laptop to see how long it takes for the application to report that I’m down, how often it checks and what exactly the outage looks like in the log. Here’s where the fun starts. Background info: the network monitoring server is configured with a threshold to determine if a host is really down, or simply experiencing packet loss. The default it was set for is 50%. In other words if you lose more than 51% of your packets, the application considers you down. It then checks every 5 minutes to see if you come back online.

After we powered off my laptop, it did not say my computer was down, just experiencing packet loss. After 15 minutes, I became suspicious (and impatient) and asked that we open a command prompt on the server. We tried pinging the laptop’s ip address manually and found something interesting. Check out the results:

C:\ >ping 10.99.10.129

Pinging 10.99.10.129 with 32 bytes of data:

Reply from 10.44.10.37: Destination host unreachable.

Request timed out.

Reply from 10.44.10.37: Destination host unreachable.

Request timed out.

Ping statistics for 10.99.10.129:

Packets: Sent = 4, Received = 2, Lost = 2 (50% loss)

It seems like a router along the way technically provides a reply even though it is, “Destination host unreachable”. The monitoring application took this as a generic ICMP reply. The analyst I was working with was initially upset, because he thought that the monitoring system had some kind of bug. After seeing the ping messages, he realized that his network architecture was affecting the way the management system behaves.

After reviewing the trace, we found something else.

It seems like his default gateway is sending an ICMP redirect, which is then followed by the Destination host Unreachable.

We identified something that he can now take away and address. I cautioned him that this may have been the case from day one, or after a network change. I also gave some advice that he should do some homework to determine why router 10.44.10.37 is responding? Is there a cache timeout that will eventually address, etc… Why 10.44.10.1 is sending the redirect? Is there a way to configure the network monitoring application to disregard the ICMP Destination Unreachable messages.

I also reminded him of what I said at the start of this exercise, if you do a baseline correctly, you will probably end up with some work to do

Some analysts will avoid baselining for this very reason since they have enough to do, but I it has 2 huge benefits:

1. You may uncover network issues that are constantly recovering in the background until one day when it doesn’t recover.

2. You get a real understanding of how your applications, clients, servers and network devices behave in a real environment. This information cannot be taught anywhere but in your own backyard and I call it ‘network tribal knowledge’.

Enjoy.

Flashback; Wireshark Trace File Reporting Using Excel

 The toughest part about packet analysis is ‘visualizing’ the packet flow. For example, an increase in packet rate, delay, etc…

A technique I like to show people in my classes and seminars. It is basically how to take a trace file and create an Excel Graph.

You can use this with any other text files, heck a guy in one of my classes used it for his hockey pool. I kid you not. Lol

Flashback: Configure Cisco As A DHCP Server

 When I conduct my classes or labs I prefer to create an isolated network, the first thing we need is a DHCP server.

The other option would be to statically configure an ip address on each device and risk typos and duplicate addresses. Then there is issue of trying to assign static ip addresses to smartphones, tablets and IOT devices.

When though I used Cisco’s packet tracer in this video, I have configured a few 8 port fanless Cisco switches with DHCP with no issue.

In this video I walk you through how straightforward it is to configure a Cisco router as a DHCP server.

Enjoy.