What’s New in the Euphonium Release

Maturity is one of the main themes in the 5.0 Eupho release. We've added capabilities around code-less integrations using our new Leap Entities and Andriod deployments for our User Interface among other great improvements. There are a lot of great things going on in the Eupho Release.

Leap Core

As Leap gets into more implementers' hands we took some feedback regarding creating 1) better performance and 2) a more consistent and usable execution lifecycle. A great deal of work was spent on 'cleaning up' the flow and streamlining it. Additionally, we saw the need to add additional handlers in the area of Implementation selection (a feature allowing us to dynamically choose an implementation). This is a very important feature for implementers operating in multi-vendor sites. See the Execution Lifecycle below:

Leap Entities

Data acquisition, and some of the associated data actions, is core to any system. Many systems permit minor flow changes with table settings, configurations, and exit points. However, changing settings, policies, and configuration only gets you so far. Sometimes, you might just need to get access to some additional bit of data to avoid a lot of extra keystrokes on the floor. So, being able to create abstract entities, even entities exposed from other systems, and augment or reshape them can produce more desirable results in a system.

A new feature to the Leap Framework, called Leap Entities, provides a whole new set of capabilities in this regard. Leap Entities permit you to define an abstract, vendor aware, entity (data item or action) which has some defined attributes:

  • Taxonomy. This is the lingua franca the system with which you are communicating – a way to describe data (what data is called and how to reference it). It supports the definition of a base Taxonomy, say for BlueYonder 2019.1 it might be called BY2019, and any number of foreign (vendor or system) taxonomies. BY2019 calls the pick identifier a wrkref while another system might call it PickID. Our XML-based taxonomy definitions provide a means of understanding the basic ways disparate systems reference similar data.
  • Projection. Where the taxonomy tells us how to describe data, the projection tells us how to form the data – the format of data payloads. The days of flat structures ended with the introduction of XML and have been further deprecated by the popularity of formats like JSON. Both payload formats permit convenient and ubiquitous ways of defining and communicating complex objects. The XML-Based projection definition provides a roadmap for the Leap Architecture to create complex object payloads on the fly.
  • Transformation. From an integration perspective, a big part of mediating the interchange of data between systems is handling the "getting from here-to-there" problem. In other words, how do you take on the actual transformation? With the taxonomy and the format of the payload defined (the projection) – the last step is the actual transformation. In most systems, these 3 elements (especially transformation) are external to the architecture. They would require an external system like Mulesoft or WebMethods to take care of this step. This is NOT the case in the Leap, Always Integrating, architecture. In this architecture, the transformation step is just another configuration, performed in-line during service execution. It permits the definition of custom transformation adaptors or the use of XSLT. Thus, the necessity of an external integration tool or framework is largely eliminated.

Below is an example of the Entity configuration for a data service for interfacing with robots. The base taxonomy is BY2019 Warehouse Management System, and the destinations are Locus Robotics and 6 River Systems. Note the highlighted differences in the configuration: TransformationConfiguration, ProjectionFileName (both extracted from a Swagger file), and a TaxonomyFileName.

Locus Robotics Entity Configuration:

6 River Systems Robotics Entity Configuration:

See a short view of doing a codelsss integration to these two vendors in the video below.

Super Entities

As we were developing our entity framework, we found that not all vendors had their APIs completely fleshed out, had implemented important variations with custom filters or ODATA queries, or were just missing important elements. To handle this, we create the idea of a Super Entity. This is a concept like a Superclass in object-oriented programming. We can abstractly redefine the Entity via configuration. This permits us to retrieve data from multiple services, or even multiple disparate systems and return the data in a single entity request. Once again, this uses the core capabilities of the Leap architecture to define, in XML content, a set of flows that are bound under one Super entity.

Leap Execution Activity Framework (LEAF)

The Leap Execution Activity Framework (or LEAF) provides the framework for a distributed, cloud/hybrid, multi-site, activity-based coordination, and streaming processing. LEAF allows you to define the activities, but not necessarily how they will be accomplished; to define the requirements of an action or activity without knowing who or what will execute it.

We started thinking about this idea about 3 years ago as we were helping one of our software partners abstract robotics and machine/human interaction for automation. Very tactical, specific, and proprietary software packages, generally called Warehouse Execution Systems (WES) have been doing some of this work since the 1990s. But to them, everything seemed like a new problem, one which they have to create integrations for – almost as if starting from scratch with each new system.

Frankly, it seems a fruitless effort to just consider this an interface problem without addressing the coordination challenges these sorts of systems, inevitably, face. So, we came up with a strategy for modeling interactions instead of interfaces to de-couple the functional/coordination challenges from any specific technology. The idea of creating a set of general, reusable services, to coordinate the execution and aggregation of activities, emerged. We call this concept Execution Activity Stream (EAS) systems.

Using the concept of Actors, Activities, and abstract data elements, an EAS-based System would contain an extensible set of verbs and the payload that describe activities and observations.

Using LEAF you can create the verbs within an EAS-based system to:

  1. Construct an on-prem or cloud/hybrid WES for single-site or multi-site operations.
  2. Construct an automated Task Managing system (Distributed Work Manager) that includes both humans and robots. It could further take guidance from Machine Learn/AI systems to alter priorities or change the actors involved from humans to robots to some other hardware automatically.
  3. Direct picking to Pick-to-light, Good-to-Person, robotic co-picking bots, or plain-old humans and record all necessary observations along the way (travel start, travel end, verification complete, etc).
  4. Conduct cases on a conveyor and record the movements (divert confirms).
  5. Guide trailer movements in the yard and record placement. Or, in an RFID-enabled yard, pick up any trailer position observations during yard jockey movements.
  6. Support gamified applications by allowing for activity injection and dynamic groupings with goals.
  7. Constantly feed WorkForce Management (WFM) systems for labor data and the predictive shifting of resources.
  8. Support stream-queries to feed Machine Learning and AI systems.

The basic flow of LEAF is shown below:

The Leap FORM User Experience team has really outdone themselves. The big shift in the Eupho Release is the ability to render an Android App (Android versions 6-8) in addition to a Web Application. This brings a series of additional, on-board, capabilities including the use of Bluetooth audio, accelerometer data, location data, etc. Some of the other highlights of the changes include:

  • Internationalization (I18N). We have added automatic I18N sensitivity to the UI. Locale may be selected at any point in the application and the UI will react to it.
  • Chartjs Integration. The popular open-source tool for creating charts and graphics is now available as a Form UI component.
  • Audio Cues. Audio cues and other implementations of Text-to-Speech are now available with simple tags added to the form definition when used in an Android App. The speech also reacts to Internationalization.
  • Card Component. The Card component gives us a great ability to create very simplified touch-screen, menus. It can also be used for other portions of a flow where the application user has a simple choice to make. Here is an example:
  • Android Intents. This technology permits the UI to seamlessly integrate to other applications running on the device. Some examples of this would be to interact more directly with the on-board scanner and wearable technology.
  • ProGLove Display integration. ProGlove is a unique 'wearable' technology which creates hands-free scanning for eComm, Pallet Building, and other applications.

Android Apps – Content-driven Applications

Leap FORM now supports both Web-based and Android deployments. Now, for example, with the new generation of Android devices making their way to the warehouse floor, we can put great Apps onto this new hardware. But one of the big problems with this is the fact that the Apps might require regular updates to get bug fixes or enhancements to the floor.

Managing Apps on 250 industrial mobile devices, which are used constantly 2-3 shifts per day, is a much bigger problem than worrying about downloading the newest version of Uber Eats to your phone every few months. It can be a difficult and time-consuming coordination problem. Our solution? Separate the App on the mobile device from content yielded by the App. In other words, the forms and flow the users see running within their App (the look of the forms and the flows) are content. In our case, we define them in XML, store them as resources, and fetch them at run-time to render the App. It can then be managed and distributed like content - and not EXE or APK files which require installation on every device. Here is the breakdown of how we did this.

Basic Screen Definition:

Basic screen configuration is stored in XML and rendered on-the-fly by the ElasticUI Form Engine. Note the tags for I18N (Internationalization) configuration. At the time of writing this document, the ElasticUI supports 13 of the most commonly used languages including multi-byte languages like Hindi. An example of a screen definition is below.

Example of Adding some Advanced Features:

To demonstrate some of the more advanced features of the ElasticUI, we teamed the UI framework with the smallest (easy to holster), least expensive, industrialized mobile device we could find (Zebra TC-20 – about $500/USD) for this example.

See the very short (one minute) video of our ElasticUI below, showing voice cues and a tightly-coupled integration with a unique wearable product called the ProGlove Display.

The behavior of both the ProGlove Display and the voice cues were added to the cycle count flow by a pair of simple tags in the form definition XML.

In the case of the ProGlove tags, they look like this* on the first from:

And this on the second form:

* For example only, in a projection application the DATA would be coming from the application dynamically

Similarly, the voice cues are configured in the XML and are Internationalized.

Scale, in music has to do with notes ordered by pitch. In the physical word, scale has many meanings, most important for us is the computer term having to do with scalability. Scale is our Platform-As-A-Service and allows you to deploy on-premises, on the cloud, or a hybrid. You can add Virtual Machines, create Software Defined Networks (SDNs) and manage availability from an implementation neutral User Interface.
Sequence, in music refers to a repeating motif. In the physical world, sequence speaks to a particular order which related events follow. For Attuned Labs, this is a configurable pipeline processing engine, great for high-speed, sequential processing situations seen in IoT and real-time data collection situations like warehouse management systems (WMS)
Other Releases
Drum Kit
Release date: 04/08/2019

Lots of new thinking went into another big release from Attuned Labs – Leap 4.0, Drum Kit. We tackled one of the big things we've been wanting to do for years – write a better context engine which improves upon our previous work in the MOCA context processor. Leap Advanced Context Engine, or LACE, is the next generation context processor. Learn More

Cowbell
Release date: 11/03/2017

Massive upgardes all round. Scale run, heavily during beta by an IoT company. Forms got Angular 2/4, Ionic Framework, custom components abilities. Leap got a full set of eclipse plugins, database support for Oracle, SQL Server, MySQL, PortressSQL in addition to Cassandra and Hbase. Currently used by an IoT company in our early adopter program.

Banjo
Release date: 1/11/2016

Lots of performance improvements, Form support for CE-based industrial devices back to CE-5 devices (1990's devices). This is the first release to get wider deployments. Dozens of WMS systems.

Accordion
Release date: 5/11/2015

Our initial release, used in a couple of Warehouse Management System(WMS) sites white-labeled under a Transportation Management System (TMS).

Get In Touch