Real-Time Embedded Systems

CIS 690 with Dr. Neilsen

Accessing CAN Controllers Remotely via Netmeeting

Sam Marten Project Overview

Here at Kansas State, off-campus engineering students do not have immediate access to circuit boards (namely CAN controllers) on which students here learn to program. The price of these boards is high, therefore, making off-campus students purchase CAN controllers and use them at home is not a feasible solution. This poses a problem in that off-campus students are not able to take classes that they could otherwise if they did have access to these controllers.

The purpose of this project is to allow students who do not have access to CAN controllers the ability to write programs and run them on these controllers remotely. To do this, I am employing the services of Microsoft Netmeeting.

Microsoft Netmeeting

Microsoft Netmeeting is a free Microsoft product that allows users to create conferences via the Internet. It supports such features as video, audio, and file transfer as well as the ability for a user to run and control shared programs on a remote machine. The only drawback to using Microsoft Netmeeting is that it requires a Windows platform on which to run.

User’s View of Architecture

The architecture of this system is very straightforward. A remote user will navigate through the Internet to a particular page. At this page, he/she will enter a username and password. If the username and password are incorrect, the user will be sent a webpage notifying him/her as such. If the username and password are correct, the user will be sent a webpage that has an embedded Netmeeting object. The user will then wait to be contacted by a target machine that has a CAN controller connected to it. The user will then be able to join a conference already set up on the target machine. Video will be displayed of the actual CAN controller and programs on the target machine that program the CAN controller will be made available to the user. After writing a program and flashing it to the CAN controller’s ROM, the program can then be execute. Results of the program execution will be visible to the user through a series of blinking LED lights on the CAN controller. Once the user has edited and run a program to his/her satisfaction, he/she can disconnect from the conference.

Actual Architecture

Once a user sends a username and password to the server, a check will determine if the username and password are valid. If not, a webpage will be sent back to the user notifying him/her that an incorrect username or password has been sent. If the username and password do check out, a database will be contacted and information for available target machines will be returned. If no target machines are available, a webpage will be sent to the user notifying him/her as such. If there is a target machine available, its status field in the database will be changed and that target will be contacted. The server will send the target machine the Internet Protocol (IP) address of the user. The target machine will call the IP address of the user and wait for the user to join the conference. If the user does not join is a specific period of time, the target machine will drop the call and update the database saying it is available. If the user does join, then the target machine will share a program with the user that allows the user to program the CAN controller. Once the user ends the call, then the target machine will update the database saying it is available.

Components

The architecture of this project has produced several components that need to be created and work in conjunction with each other to make this system work. We wanted to, at least initially, create these in a platform-independent manner.

User Verification

The first component is user verification. Creating a web page that has user name and password textboxes seems the most appropriate approach. We want users to be able to access this system from anywhere, so posting them on the Internet seemed like the only option. However, even after we have the username and password, we still need to verify that they are valid. This is where the cgi script comes into play.

Because we wanted the system to be built in a platform-independent way, we felt that

JavaScript would provide the best means of validating passwords. I had little experience with JavaScript, so I took a few days to play around with it and determined that it would be fine for validating usernames and passwords. Problems began to arise, however, when

I wanted it to communicate with the main server program. Finding good resources on getting JavaScript to communicate with remote applications proved to be a big problem.

Therefore, JavaScript became a dead end. Next, I turned to VBScript. Because Netmeeting is strictly a Windows-based application,

I figured that getting away from a completely platform-independent approach would not hurt the project too badly. Again, VBScript looked as though it would be fine for checking usernames and passwords, however, I could not find a lot of good documentation on how to access remote applications with VBScript.

Not much mention has been made of servers up to this point, but it had been decided that the Microsoft Internet Information Server (IIS) would be our server of choice. Like

JavaScript, I have had little experience with servers, however, the decision to use IIS seemed pretty logical. Our target machines would need to be running Windows, so, to remove conflict and confusion, it makes sense that our server would be running Windows as well. The decision to use IIS also helped solve the problem for creating a script that could communicate with remote applications.

IIS allows for dynamic link libraries (dlls) that can be placed in the IIS’s common gateway interface directory and be invoked just as a regular script would be. Microsoft

Visual Studio 6.0 provides a dll wizard which makes creating dll scripts very simple.

Because we are not limited to a simple scripting language, we have more robust tools at our disposal, and a socket can be created and opened in the dll that will communicate with a remote application. Central Server

Now that we have discovered a way to access remote applications through a script

(actually, a dll), we need to create the program that will accept messages from and pass messages to both the dll and the target machines. We will, of course, have only a limited number of target machines connected to CAN controllers and the possibility does exist that all of these machines will be in use when a new user logs in and wants to access one.

Therefore, initially, I thought having a central server would be a good idea because it could hold the IP addresses of the target machines and keep track of which ones were currently in use and which ones were not. At first, before entirely jumping ship on platform-independence, I figured that I could write the central server program in Java.

Actually, this would not have been pretty simple to write in Java, but, as you will see shortly (and probably noticed in the architecture description), that became entirely unnecessary. Before I wrote the central server program, I figured it would be beneficial to work on the target machine application.

Target Machine

The most daunting part of this project is dealing with Netmeeting itself. Although I have found example programs that provide wrapper classes, learning Windows programming is not an easy chore. Netmeeting is written based on Microsoft’s Component Object

Model (COM) which involves interfaces and several initialization techniques with which

I was also not familiar. I spent quite a few days this semester looking into and trying to learn several of the features of COM and have only recently begun to gain to good understanding of how it works.

Like the main server program, I wanted to see if I could write this in Java, however, from the pages that I found on the Internet that dealt with Java and COM, they were all written by Microsoft and involved Microsoft J++, which only runs in Windows. Therefore, the choice was pretty clear to use Microsoft Visual C++. It is designed with COM in mind and will, hopefully, be the best development environment for working with Netmeeting.

Although much of the code is not yet written, I have so far been able to automatically create a conference and call a remote machine using the remote machine’s IP address.

Design Changes

There have been several, smaller, design changes mentioned up to this point such as using Microsoft Visual C++ as opposed to Java and a dynamic link library as opposed to a standard script for logging in purposes. However, the biggest design change I have made so far is ditching the main server application in favor of a database that will store the current status of the target machines.

I created a simple table in a Microsoft Access Database that has fields for the IP address of the target machine (a string value) and the current status of the target machine (a

Boolean value). The dll program will access the database to see if any machines are currently available on the basis of the status field. I feel that using a database instead of a central server program simplifies my design in several ways. First, it simplifies the design greatly. Writing a server application that would keep track of which target machines were busy and which were not would require direct communication between not only the server and the target machines, but also the server and the dll program. Using a database only makes the dll program contact the target machine. On top of this, the database is already written. All that I need to do is create some ODBC calls from the dll program and target server application. These calls alone will be able to handle everything that the main sever application would normally have handled. Finally, it helps with atomicity. Several threads would have needed to be implemented with the main server application that would be listening for calls from the dll program. The database has implicit atomicity so when the dll program receives a recordset from the database, it can maintain this recordset dynamically. So, if a target machine were free and then becomes busy, the dll program would be notified of this through the dynamic recordset.

Accomplished This Semester

Through the end of this semester, I was able to get the outline of the dll and the target application as well as create the database that they will both access. I spent a lot of time this semester going through Internet tutorials (JavaScript, VBScript, Perl) and trying to educate myself in the ways of Microsoft Visual C++ as well as COM, so I didn’t write a lot of code. Most of the code that I did write was more or less altered from examples that

I found either in the Netmeeting Software Development Kit or that I found on the Internet. I now feel that I have a pretty good understanding of COM now, and am exciting at the chance to finally start writing my own code.

To Finish This Summer

This summer I need to do accomplish several tasks before I can consider this project to be complete. First, I need to finish writing the dll. This will include making sure it connects properly to the database, that the dynamic recordset works correctly, and finally, that it connects properly to the target applications. Second, I need to finish writing the target application. As I mentioned earlier, I’ve been able to get it to automatically create a conference and make a call to an IP address, now I need to get into its guts a little further and make sure that functionality is added to certain events. For example, files cannot be shared when not in a call, so, once a call is established, some code must be written to make sure that the necessary files/programs can be accessed and used by the remote user.

Also, when the call is ended, the database must be updated to reflect that the target machine is no longer in use. Finally, for security purposes, I need to find some way to encrypt the username and password which will be sent over the Internet. IIS offers a way to log on to its server which uses SSL, however, I am not sure that is the best way. I am looking at the possibility right now of using one way functions in conjunction with the date or, possibly, using https.