I had worked for Ericsson Research Canada in Montreal for many years (1990's) in mobile telephony especially APZ or AXE. Since I left Ericsson, I have worked for many companies and had a chance to compare technologies with Ericsson proprietary APZ.
APZ is superior with PLEX-C and Test
System as they offered features to debug and load patches on live nodes to fix
issues in ASA (APZ's assembly language). With ASA, we could even develop quick features and load on
switches instead of going through a complete software development cycle by
developing in PLEX-C, testing system, and then deploying system normally, i.e.
slower deployment of products to customer sites.
PLEX-C is an old programming language as
compare to other object oriented languages such as C++, Java, Python, etc.
However PLEX-C helped to decouple large and complex systems into subsystems
easily. Each subsystem could communicate with each other via a pre-designed
protocol, which could be verified easily by using signal descriptions. We could
say that system developed with PLEX-C is like a protocol application, which is
easy to understand and debug.
We could say that PLEX is a programming language specializing in packet
communications such as banking transactions, telecommunication systems, IoT
applications, etc. With relational database, it could offer developers an
excellent platform for many applications.
You could take a look at ANSI-41 standards
for TDMA, it is like sequence diagrams for PLEX-C. By the way, block diagrams
could be dropped. A sequence diagram could be extended to add relevant
information, which was normally in a block diagram. This would help to reduce
development cost. I have never looked at a sequence diagram or block diagram to
understand mobile telephony system on APZ. I had only used source codes, signal
descriptions, and Test System.
Test System helps to debug and understand
a complex system quickly with help of signal descriptions and PLEX-C codes.
This is a data flow model as compared to other program languages as logic flow,
which is harder to decouple, understand and debug.
Test System could be upgraded for tracing
on live nodes. Currently we need to write scripts to limit tracing shown on
live system, i.e. we couldn’t do any tracing without advanced planning.
The only draw back from PLEX-C is its file
database. If APZ could be upgraded to offer relational database, it would be a
winning product. PLEX-C would be extended to offer programming statements for
developers to use relational database.
With this upgraded APZ, software
development would be quick and easy, i.e. less expensive and possible lower
price quoted to customers.
Speaking of user interface, the upgraded
APZ could offer an interface or ports to external terminals, which support GUI
to users. Data entered plus command actions would be committed to the upgraded
APZ in format understood by the APZ, e.g. command lines. With separate GUI,
Ericsson could sell upgraded APZ to customers as modern technologies. However
the performance of the upgraded APZ is unchanged or un-impacted by adding many
OS codes, which could slow it down.
The external interface (APY) port could be a fast proprietary Ethernet port, which would accept data from a terminal to query data from the database in order to present to clients in a graphical screen or animated results. Data or communications from the terminal to the APZ would follow specific protocols in order to exchange data OR committed changes to the database or system applications.
Regular Ethernet port(s) or telecom (CCITT) ports are also needed for APY applications communicating with other systems.
I have also written a design proposal on
parallel processors, which were based on PLEX-C programming language. That
means APY could offer parallel processors as super computers to
customers.
To optimize development costs, the “less
powerful” (less expensive parallel processors) APY could be used for
RBS or RAN in addition to MSC and HLR.
The upgraded APZ (APY) is like power super computer. The PLEX-C plus
relational database is very easy to learn to software developers.
-----------------------------------------------------------------------------
2022-01-12
Developers, who had never worked with
PLEX-C, could be puzzled about whatever I wrote above. You could answer the
following simple questions?
·
Can you read the
technical specification of a product OR its functionality on the UI, and then
you can “guess” the programming logic of the application by looking into the
database’s tables? I could.
·
Is it easier to read
the entire flow of data (TEST SYSTEM) from beginning to the end of an
operations OR using a conventional debugger to step in the entire programs to
follow the logic? The debugger may jump “crazily” from a class to another
class. Test System could be consider similar to “unit test” as “signals with
accompany data” entered a program module (block) and out with “signals with
expected data”. By setting proper traces, you will get the entire flow of data
from start to end with a single action for all program modules involved, e.g. making a call from MS-A to MS-B. You
don’t need to step by step following logic of a developer.
·
Is this easier to
read data or reading many lines of codes?
By the way, I would prefer to write codes
than reading codes by others. Many software developers “preferred” to show off
their “sophisticated” mind by writing complex codes, but it was not needed. Getting applications working and deploying to a customer site would be better than spending time figuring out what a developer wrote?
During my years at Ericsson, many code reviewers were very picky to ensure that codes were written in a simple way and meet AXE’s design rules.
2022-01-18
If Ericsson used its APZ technology to
develop PC’s OS with PLEX programming language, relational database, and GUI
(similar to VB or C#), I would pick this type of PC for complex applications
competing to medium powerful server’s systems. Parallel processors could be
supported by this PC to enhance its processing power.
IBM Mainframe or powerful servers would be compared with APY.
I heard that PLEX-V is an upgrade of
PLEX-C programming language plus relational database programming statements.
To make PC attractive to software developers,
Ericsson could create a virtual holder similar to Java Virtual Machine (JVM) or VMware for legacy Microsoft Windows apps. Of course, those apps would run slower than
native applications developed with PLEX-V directly.
Developing applications would be quick and
easy, i.e. saving time in R&D or costs.
As many people out there said: personal computers
with parallel processors like this would be competing in the rank of mini-super
computers.
In computer history, many super computers
have been invented and developed, but many of those have become obsolete or
unpopular because its programming languages were not developer friendly. PLEX
is a simple language, which makes its applications similar to TCP/IP or any
popular protocols out there.
The question is if you’re familiar with a
protocol and love protocols or not. Any applications offered user access
remotely over Internet are using TCP/IP as transport layer, thus packet data
communications.
Anyway I like protocol and Microsoft’s
programming languages are not good enough for packet programming. Its “forever
loop” at an Internet port does slow down a computer significantly. I did design
an “Internet Interface Manager” in
one of my post using PLEX to avoid forever loop, i.e. speeding up system
performance.
-----------------------------------------------------------------------
2023-01-20: I spoke about this earlier for APY with PLEX-V = PLEX-C + relational database. APY coupled with parallel processors would be the best candidate for financial systems such as bank ATM, bank tellers, stock trading, etc.
Those financial systems are driven by short transactions such as withdraw, buy/sell stocks, etc.
Those are like protocol transactions, which are supported by PLEX programming languages or IoT.
The UI could be provided by a separated computer server connecting to the APY's database for display. New transactions or configurations must be via an internal protocol with the applications on APY. Using internal protocol instead of committing data changes to database directly is to avoid data corruption because system is live.
However liability of banking industry is very high as compared to telecommunication, which is around $1M/min down time. By the way, financial system is simpler than mobile telephony system.
IBM is dominating the landscape of bank systems with IBM Mainframe, and financial institutions are not jumping to another systems OR addicted to high/modern technologies.
That's reason why Ericsson should not step in this industry.
No comments:
Post a Comment