WO2012039713A1

WO2012039713A1 - Accessing an embedded application in an embedded device

Info

Publication number: WO2012039713A1
Application number: PCT/US2010/049904
Authority: WO
Inventors: Russell Crisp
Original assignee: Arris Group, Inc.
Priority date: 2010-09-23
Filing date: 2010-09-23
Publication date: 2012-03-29

Abstract

Methods for providing command line access to embedded applications running on an device having a host application and at least one embedded application are disclosed. The host application can redirect its input to the embedded application when the input identifies the embedded application. Communication pipes can be used to direct input from the host application to the embedded application. The method can be used in CPE devices with embedded applications to provide command line access to a MTA.

Description

ACCESSING AN EMBEDDED APPLICATION IN AN EMBEDDED

DEVICE

TECHNICAL FIELD

[0001] This disclosure relates to accessing embedded applications.

BACKGROUND

[0002] Cable Modem Termination Systems (CMTSs) residing at headend locations can communicate with customer premise equipment (CPE) devices, such as multimedia terminal adapters (MTAs), set top boxes (STBs), and cable modems (CMs) to deliver high-definition digital entertainment and telecommunications such as video, voice, and high-speed Internet to subscribers over existing cable television networks.

[0003] For example, referring to FIG. 1, in a DOCSIS-based system, traffic

(e.g., data, video, and voice signal) is transferred over a cable network 130 between a CMTS 110 and a CM 120. The CMTS 110 is located at a cable system head-end and the CM 120 is located at a subscriber's home. The CM 120 is primarily used to deliver broadband Internet service to a computer. Thus, once the CM 120 receives traffic from the CMTS 110 via the network 130, the CM 120 typically delivers it to another CPE device such as a personal computer 140.

[0004] However, CPE devices generally can include any equipment at a subscriber's home. For instance, as shown in FIG. 2, a CPE devices can also include a multimedia terminal adapter (ΜΤΑ) 150 can interface with the subscriber's telephone 160 and the cable modem 120 to deliver voice-over-IP (VoIP) services (such as voice communications, call waiting, three-way calling, voice mail, and fax support).

[0005] Other CPE devices can either connect to the CM's LAN interfaces, can be embedded with the CM 120 in a single device, or can be a separate standalone device as shown in FIG. 2. For possible cost reduction and performance enhancement, it may be desirable to integrate certain CPE functionality within the CM. For instance, in an eMTA device, the MTA functionality is embedded within the CM. Thus, as shown in FIG. 3, the standalone CM 120 and MTA 150 shown in FIG. 2 can be replaced with embedded multimedia terminal adapters (eMTA) 170. In this way, the MTA 150 and CM 120 functionality can share various system resources.

[0006] Because of the low cost and ease of modification of an embedded Linux operating system, among other reasons, many developers have been converting to an embedded Linux operating system for certain computer systems such as embedded systems. Embedded systems generally are systems designed to do one or more specific or dedicated functions. For the eMTA 170, the Linux kernel makes it difficult for multiple applications (such as the CM application and the MTA application) to share data. More specifically, FIG. 4 illustrates an example embedded Linux environment 400 having a main host application 410 and one or more embedded applications 420. The Linux kernel 430 can manage the system's resources by, among other things, allocating to the main host application 410 and each of the embedded applications 420 their own unique process space to run their respective applications and store data. Thus, for example, main host application 410 generally does not use the process space of any of the embedded applications 420. Accordingly, when the embedded Linux environment 400 is an eMTA, and the main host application 410 is a CM application, and one of the embedded applications 420 is a MTA application, when a MSO wants to retrieve data from the MTA in the eMTA (e.g., for troubleshooting purposes), it connects to the CM IP address of the eMTA. However, in this example, the MSO cannot directly connect to the MTA. The CM application therefore retrieves MTA data through the MTA application. However, because of the process space boundaries created by the Linux kernel 430, it can be difficult for the MTA application 420 and CM application 410 to share data.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 illustrates a DOCSIS-based system for transferring traffic between a CMTS and a CM over a cable network.

[0008] FIG. 2 illustrates a DOCSIS-based system according to FIG. 1 where a standalone MTA connects to the CM to deliver VoIP services to a telephone.

[0009] FIG. 3 illustrates a DOCSIS-based system according to FIG. 2 where the standalone CM and MTA are replaced with an eMTA. [0010] FIG. 4 illustrates an example embedded Linux environment.

[0011] FIGS. 5A-B illustrate example methods for retrieving information from an embedded application in an embedded Linux environment.

[0012] FIG. 6 illustrates an example code segment processed by an embedded application/ slave console for creating and closing a pipe.

[0013] FIG. 7 illustrates an example code segment processed by a main host application/ master console for opening and closing a pipe.

DETAILED DESCRIPTION

[0014] Various implementations of this disclosure can operate to reduce the processing needed in an embedded Linux environment to retrieve information from an embedded application by eliminating the need to share information across process space boundaries. In some implementations, this result can be achieved by passing a command line input from a host application (e.g., the CM application) to an embedded application (e.g., the MTA application) so that the embedded application can process the command line input in its own process space. Although the details of various implementations are explained in the context of an eMTA, such implementations can be applicable in any embedded Linux environment having a host application and one or more embedded applications. Implementations of this disclosure also are applicable in any operating system environment having a main host application and one or more embedded applications that have process space boundaries.

[0015] Generally, in various implementations, a user can instruct the main host application to perform a given task via a command line interface. The command line interface from the main host application can be referred to as a master console. The user can interact with embedded applications via a command line interface. The command line interface of embedded applications can be referred to as a slave console.

[0016] FIG. 5 A illustrates an example process 500 operable to provide information from an embedded application in an embedded Linux environment. In some implementations, the method 500 of FIG. 5 may be applied in any operating system environment having a main host application and one or more embedded applications that have process space boundaries.

[0017] At stage 505, register with a main host application. The registration can be performed, for example, by embedded applications (e.g., embedded applications 420 of FIG. 4). In some implementations, each embedded application 420 can register as a slave console with the main host application 410. The registration can be performed by supplying the main host application 410 with a distinct name (e.g., a unique identification) and creating and opening a pipe between the embedded application 420 and the main host application 410 for inter-process communication. FIG. 6 illustrates example code 610 processed by embedded application 420 for creating a pipe. Main host application 410 stores each distinct name (e.g., in a database) in its process space.

[0018] At stage 510, the process 500 waits for input. For example, an embedded application can wait for input provided by the main host application (e.g., main host application 410 of FIG. 4). In some implementations, the input is provided only after registration of the embedded application as a slave console with the main host application.

[0019] At stage 515, input is received. Input can be received, for example, by the slave console of the embedded application (e.g., embedded application 420 of FIG. 4). Thus, each character of input received by the master console of the main host application (e.g., main host application 410 of FIG. 4) is received by the slave console of the intended embedded application. The slave console of the embedded application then becomes the running console so that the embedded application can process input in its own process space.

[0020] At stage 520, the received input is processed. The received input is processed, for example, by an embedded application (e.g., embedded application 420 of FIG. 4). In some implementations, the received input can be used to carry out various commands or retrieve data from the embedded application. Thus, it should be understood that the processing stage can include communicating information back to the user, for example, through the main host application. [0021] At stage 525, a determination is made whether the input received was a quit command. The determination can be made, for example, by an embedded application (e.g., embedded application 420 of FIG. 4). If the embedded application/ slave console identified at stage 525 has not received a quit command (i.e., "No" at stage 525), the main host application (e.g., main host application 410 of FIG. 4) will continue to pass user input to the slave console of the embedded application identified at stage 525. Thus, the main host application continues to pass user input to the slave console of the embedded application/ slave console identified at stage 525 until the embedded application identified at stage 525 recognizes a command to stop communicating with the embedded application/ slave console (i.e., a quit command). The quit command can be any predefined sequence of characters.

[0022] If the embedded application/ slave console receives a quit command

(i.e., "Yes" at stage 525), at stage 530, the communication pipe is closed. The communication pipe can be closed, for example, by the embedded application (e.g., embedded application 420 of FIG. 4). FIG. 6 illustrates example code 620 processed by embedded application for closing a pipe. Accordingly, once the communication pipe is closed, the main host application stops passing user input to the embedded application/ slave console. The process 500 ends at stage 535.

[0023] FIG. 5B illustrates an example process 550 operable to retrieve information from an embedded application in an embedded Linux environment. At stage 555, an embedded application is registered as a slave console. The embedded application can be registered as a slave console, for example, by a main host application (e.g., main host application 410 of FIG. 4) at startup. In some implementations, the main host application receives the distinct name supplied by the user and opens a communications pipe to the embedded application.

[0024] When a user desires to communicate with an embedded application, the users supplies the master console of the main host application with the distinct name of the embedded application for which it desires to communicate. A user can communicate with the main host application via any suitable communication link wherein the communication link can include the application layer functions, network or networks for end to end connectivity between the user and host application, and physical links. Accordingly, the communication links can include any system, network, or device that facilitates communication between the main host application and the user using any appropriate communication protocol (e.g., TCP/IP, HTTP, HTTPS or any other security protocol, FTP, SMTP, or any other proprietary protocol). The communication links can include a local area network (LAN) connection, a wide area network (WAN) connection, an Internet connection, or a combination of the foregoing. The communication links can include a telephone line, optical fiber, coaxial cable, twisted wire pair, or any other communication medium, or a combination of the foregoing. One or more of the communication links can be wireless using any appropriate technique to provide wireless transmission including infrared line of sight, cellular, microwave, satellite, packet radio, spread spectrum, or a combination of the foregoing.

[0025] At stage 560, an embedded application/ slave console is identified. The embedded application/ slave console can be identified, for example, by a main host application (e.g., main host application 410 of FIG. 4). In some implementations, the main host application receives the distinct name of the embedded application with which the user desires to communicate.

[0026] Upon identifying the input as the name of an embedded application, redirect mode is entered at stage 565. Redirect mode can be entered, for example, by the main host application (e.g., main host application 410 of FIG. 4). Redirect mode is entered when the main host application opens the pipe between the main host application and the embedded application identified at stage 560. FIG. 7 illustrates example code 710 processed by main host application for opening a pipe. In a redirect mode, the characters received by the master console of the main host application are passed to the slave console of the embedded application identified at stage 560. In some implementations, control of the processor is passed to the embedded application/ slave console until the pipe is closed by the embedded application/ slave console.

[0027] At stage 570, a determination is made whether the embedded application communications pipe is being closed. The determination can be made, for example, by the main host application (e.g., main host application 410 of FIG. 4). In some implementations, the communications pipe can be closed in response to receipt of a predefined string of characters. In various implementations, closing the communications pipe can be initiated by the embedded application or by the main host application.

[0028] In response to receiving determining that the communications pipe is closing, the process 550 can advance to stage 575, where the communications pipe is closed. The communications pipe can be closed from the main host application, for example, by the main host application (e.g., main host application 410 of FIG. 4). FIG. 7 illustrates example code 720 processed by main host application 410 for closing a pipe.

[0029] The process 550 ends at stage 580, the master console becomes the running console. In some implementations, the master console can become the running console responsive to the communications pipe being closed.

[0030] By utilizing the above method, information from an embedded application can be retrieved without sharing information across process space boundaries.

[0031] Utilizing the method of FIG. 5, an eMTA in an embedded Linux environment can supply MTA information to an MSO more efficiently. More specifically, at stage 510, at bootup, the MTA 420 registers as a slave console with the CM 410. In one embodiment, the MTA 420 registers as a slave console with the CM 410 by supplying the CM 410 with its distinct name, (e.g., voice) and creating and opening a pipe (e.g., utilizing code 610) between the MTA 420 and the CM 410. The CM 410 can store the distinct name (e.g., in a database) in its process space.

[0032] By passing a command line input from a master console of a host application (e.g., the CM application) to a slave console of an embedded application (e.g., the MTA application) so that the embedded application can process the command line input in its own process space, the need to share information across process space boundaries is eliminated and over head is reduced.

[0033] The processes and logic flows described in this specification are performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output thereby tying the process to a particular machine (e.g., a machine programmed to perform the processes described herein). The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0034] Computer readable media suitable for storing computer program instructions and data include all forms of non volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0035] To provide for interaction with a user, embodiments of the subject matter described in this specification can be operable to interface with a computing device having a display, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.

[0036] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination. [0037] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0038] Particular embodiments of the subject matter described in this specification have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results, unless expressly noted otherwise. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing may be advantageous.

Claims

1. A method for accessing embedded applications running on a device comprising:

registering at least one embedded application on a device having a main host application running on the device, wherein the at least one embedded application has a first process space boundary and the main host application has a second process boundary;

receiving at the main host application user input that identifies the at least one embedded application; and

redirecting user input received at the main host application subsequent to receiving user input that identifies the at least one embedded application to the at least one embedded application until a command is received to stop redirecting the user input to the at least one embedded application.

2. The method of claim 1, further comprising creating a pipe between the main host application and the at least one embedded application.

3. The method of claim 2, wherein the main host application and the at least one embedded application is on an embedded multimedia terminal adapter and wherein the main host application is directed to an application for a cable modem and the at least one embedded application is directed to an application for a multimedia terminal adapter.

4. The method of claim 1, wherein the device runs on an embedded Linux operating system.

5. The method of claim 1, wherein the command to stop redirecting input to the embedded application comprises a string of predefined characters.

6. The method of claim 1, wherein upon receiving user input that identifies the at least one embedded application the identified at least one embedded application becomes the running console.

7. The method of claim 1, wherein upon receiving the command to stop redirecting input to the embedded application, the main host application becomes the running console.

8. The method of claim 1, further comprising retrieving information from the at least one embedded application responsive to received user input identifying the at least one embedded application.

9. A method for accessing embedded applications running on a device comprising:

sending a registration comprising a unique identifier to register at least one embedded application on a device having a main host application running on the device, wherein the at least one embedded application has a first process space boundary and the main host application has a second process boundary;

opening a communications pipe to the main host application;

receiving user input redirected from the main host application based on the unique identifier; and

processing the user input received via the main host application.

10. The method of claim 9, further comprising:

detecting a command to stop redirecting the user input to the at least one embedded application; and

closing the communications pipe with the main host application upon receiving the stop command.

11. The method of claim 9, wherein the main host application and the at least one embedded application is on an embedded multimedia terminal adapter and wherein the main host application is directed to an application for a cable modem and the at least one embedded application is directed to an application for a multimedia terminal adapter.

12. The method of claim 9, wherein the device runs on an embedded Linux operating system.

13. The method of claim 9, wherein the command to stop redirecting input to the embedded application comprises a string of predefined characters.

14. The method of claim 9, further comprising retrieving information from the at least one embedded application responsive to received user input identifying the at least one embedded application.

15. A computer-readable medium having embodied thereon an computer program comprising a main host application and at least one embedded application for processing by a computer wherein, the computer program comprising:

one or more first code segments operable to receive at the main host application user input that identifies the at least one embedded application;

one or more second code segments operable to redirect user input received at the main host application subsequent to receiving user input that identifies the at least one embedded application to the at least one embedded application; and

one or more third code segments operable to receive a command to stop redirecting the user input to the at the at least on embedded application and to stop the redirection of the user input to the at least one embedded application upon receiving the stop command.

16. The computer-readable medium of claim 15, further comprising one or more fourth code segments operable to create a communications pipe between the main host application and the identified at least one embedded application.

17. A system for providing command line access to embedded applications running on a device comprising:

a main host application;

at least one embedded application;

an embedded operating system wherein the at least one embedded application has a first process space boundary and the main host application has a second process boundary;

means for registering the at least one embedded application; means for receiving at the main host application user input that identifies the 85 at least one embedded application;

means for redirecting user input received at the main host application subsequent to receiving user input that identifies the at least one embedded application to the at least one embedded application; and

means for stopping the redirection of the user input to the at least one 90 embedded application upon receiving a stop command.

18. The system of claim 17, further comprising means for creating a pipe between the main host application and the at least one embedded application.

19. The system of claim 18, wherein the main host application and the at least one embedded application is on an embedded multimedia terminal adapter and wherein

95 the main host application is directed to an application for a cable modem and the at least one embedded application is directed to an application for a multimedia terminal adapters.

20. The system of claim 17, wherein the embedded operating system is an embedded Linux operating system.

100