
The first two years of my Ph.D. have largely revolved around TickTalk , an NSF grant dedicated to developing timing APIs to simplify the development of federated, time-sensitive cyber physical systems.
In May of 2021, I lead our team to win second place (of 12) in a student design competition hosted by CPS-IoT Week, which hosts the primier conferences for cyber physical systems, sensor networks, and Internet of Things. The competition's focus was on Networked Computing on the Edge, and was hosted in collaboration with Nvidia, who graciously provided us a few Jetson TX2 development kits. Suffice to say, receiving this award is a great honor!
Our Submission to the
CPS-Week Student Design Competition
This competition served as a showcase for the ongoing development of TickTalk Python (TTPython), a programming framework for distributed, time-sensitive applications in cyber physical systems. Our framework is designed to simplify the development of such applications by building timing and distributed systems abstractions into a domain-specific language and dataflow graph based runtime environment
Our colleagues at Arizona State University have strong roots in autonomous vehicles, but have seen several pain points in the development of a smart-intersection application, in which vehicles coordinate with a centralized controller to plan their path through the intersection on an individual basis rather than per street as normal stop-lights do. This application is demonstrated on a 1/10th scale version of an intersection using RC cars equipped with LIDAR, image sensors, and Nvidia Jetsons to perform SLaM and object detection CNNs in real-time. Most application code is written in Python 3, although the CNN, SLaM, and sensor/actuator manipulation invokes C/C++ routines.
Distributed, time-sensitive applications are notoriously difficult to develop due to challenges with clock synchronization, inter-device coordination and communication, debugging, and more. Edward Andert, our smart-intersection expert at ASU, helped us understand these pain points and how they impact his ability to reason about the application. Ian McCormack (a then UG student at Wisconsin Eu Claire) and I developed networking and timing abstractions to alleviate issues with periodic sampling, network management, and sensor stream fusion. Our process and programming environment relies on a dataflow graph and message-passing architecture to improve composability and avoid side-effects due to memory sharing. These abstractions are written in Python 3 as well, such that they mesh well with existing application code.
These abstractions helped Edward find subtle issues within his implementation and reduce the end-to-end latency of his system by around 33% (125ms down to 88ms). The abstractions, particularly for sensor fusion, do come with an overhead, which our runtime instrumentation clocked at 5ms additional processing time along the critical path. We can safely ignore this effect for this application, but it does suggest a limit on how effective this strategy would be for applications whose timing requirements enter the low millisecond to microsecond regime.
As lead on this competition submission, I was responsible for setting the goals of our submission (and retuning them as we progressed), designing the architecture of our abstractions and their interaction with the existing smart-intersection application, facilitating integration of individuals' contributions, and designing the poster and presentation, which we gave as a team.
Please see our presentation slides, video, and poster!
Wait, But What is TickTalk?
No, it's not related to the now-mainstream video-sharing platform! The grant was written before ByteDance rebranded the platform...
TickTalk is all about simplifying development of time-sensitive applications for cyber-physical systems. As the IoT burgeons, more distributed, heterogeneous applications become feasible. However, the tools to handle the distributed parts of these applications are largely unchanged or nonexistent. Each device (or device type) has custom code to control its node-local behavior, and each interface (both in the application and network) is uniquely designed and tested. Protocols like COAP help standardize the format, but say nothing about behavior at the application level. Any system containing more than a few device types requires a team of experts to manage the interfaces (which scale with N2 for N devices).
TickTalk's long-sighted vision is to enable a more holistic programming interface, where the user declares what they want to happen, but relieve the user of dictating how that must happen. A fundamental component is simplifying the user's interaction with timing, which includes both data and control aspects for time-series, sampled data and coordinated action with the physical environment, respectively. Managing these timing requirements in the distributed context is challenging to reason about and debug, largely due to clock synchronization errors, reproducibility (related in part to best-efforts networking), and observability.
TickTalk Python is our attempt to see this vision through, by presenting a Python-based coordination language that includes meta-syntax to help describe where code runs in a system and what types of time-based control (such as periodic sampling or deadlines on actuation). This glue language compiles into a dataflow graph that can be mapped onto the system per user requirements and objective functions like end-to-end latency. The nodes in the graph contain abstractions for synchronizing inputs (cognizant of synchronized clocks), executing user code, and forwarding output data to whichever device contains the next node in the graph.
My contributions have centered largely on the model of computing, i.e., dataflow, and timing abstractions that account for clock synchronization error and data validity. This has served as a fantastic learning experience in the field of distributed, real-time systems, as I delved into message-passing architectures (like dataflow process networks and petri nets) and real-time systems architectures (like the Time-Trigged Architecture and PTIDES/PTOLEMY). I have a great deal of respect for Dr. Edward Lee's work in Cyber Physical Systems.