Toward a Functional Overview of Thesis Development and Software Development

My being a student of electronics and computer networking, in an associates level program, and -- for some time -- a fan of free/open source Linux software platforms such as Debian GNU Linux, and broadly a fan of academic literature about computing, I understand that there is an existing body of work with regards to project management, at least insofar as with regards to software projects. My being furthermore of some experience with regards to the arts aspects of the humanities, including visual creative arts and the performing arts, I'm of a point of view that software projects are not the only kinds of projects under the sun.

Personally, I haven't encountered a lot of literature in academia, insofar as project management. I've read some little about the Capability Maturity Model (CMM), perhaps a sort of monolithic or centralized project management model, and some little about Scrum. I've not read a lot about "Extreme Programming" (XP) -- sort of an older agile project management trend, in a sense -- but I understand that it involves an iterative process. I've also read a little about the ideas management method proposed by Scott Belsky, in the book, Making Ideas Happen. Belsky's Action Method addresses more of a creative approach, juxtaposed to what one might expect that an implementation of monolithic CMM might be like, at a personal level. Of course, a large project might need a large management information system (MIS) to manage it by, entailing a certain degree of formalism throughout.

Personally -- as my being a student, at this time in my life -- I'm more interested about management methods for small-scale, original projects, rather than for projects developed under monolithic requirements. As a person of any manner of a creative bent, and a student of a technical field, with some self-managed knowledge of computer programming language, personally I'm interested in developing a project management system for small-scale thesis development projects, and for small free/open source software (FOSS) projects -- in an abstract sense, two types of project. In juxtaposition to monolithic project management methods, personally  I'm of an impression that each of a thesis type of project and a FOSS type of project might be -- in the most of which -- each managed individually, and by a small number of contributors.

To inquire, "How does a FOSS project begin?" or similarly, "How does a thesis project begin?" perhaps the Action Method might present the most readily applicable practical model for such a context -- as towards an ideas management phase of project development.

Towards a View of Idea Management

Aside to the metaphysical aspects of positive intention,  ideas are some of the raw stuff of academic work. Parenthetically, the reader is offered the author's sincerest apology for a lack of formal citation, to that effect. Perhaps the reader may agree that it is a valid assertion. Broadly, it may be a matter of philosophy -- namely, towards a relevance of ideas, in academic work -- furthermore, a practical matter of a functional application of intellect to a formal or informal task. Whether or not that may satisfy all of a model of "Left brain" and "Right brain" knowledge, perhaps it at least serves to present two juxtaposed views about -- in broad sense -- a relevance of ideas.

Aside to this thesis, the reader -- at any time -- might wish to criticize the author's style of writing, if it may serve as a convenient alternative to an addressing of any of the content of the discussion. The author has an idea that the ad hominem mode of discussion occurs in numerous forms. Inevitably, there will be another biting ad hominem criticism over my own writing. At that, I might wish to only address the topic: Philosophy.

Ideas and Theses

In a capital sense, ideas cannot be exchanged for raw currency. Thesis articles -- insofar as being works made as expressions of ideas -- thesis articles may not seem to be terribly profitable, either, not in any manner of an immediate economic sense. In a practical sense, a thesis article about barns does not in itself build a barn, though a thesis article may ever attract some manner of attention from a barn builder. In a literate society, thesis articles -- as literate works -- thesis articles are one manner of a textual medium on which ideas may be communicated.

Without any too lengthy reference to the Business Process Management Notation (BPMN), hypothetically, a model can be developed for a process of thesis article development. Certainly, thesis articles are works developed in chronologically linear manner, from a discrete "Start point" to a discrete "Stop point," at which time the work is published or filed away, if not altogether abandoned.  The process of developing a thesis paper, essentially, is a process of developing ideas, and expressing those ideas on a written medium. In that sense, it may be analogous to a development of any of other forms of prose, and forms of written verse, such as poetry.

Thesis articles, as ideal media,  thesis articles may not seem to serve any single, exacting functional role in society, except insofar as being required of some academic programs. If all of the world is a functional world, thesis articles may not seem to have any obvious relevance -- at least, outside of any manners of academic cultures as in which thesis articles would be any manner of a common fare. Ideally, even in proceeding from academic cultures in which learning itself would seem to be presupposed to be something akin to "Just press play", there may be a relevance recognized of thesis articles as discursive works, in a literary medium, works communicating ideas, and serving in further development of ideas. Hypothetically, a diagram of the ideas content of a single set of thesis works and the ideal derivatives of thesis articles may be all made in a single directed graph. In a practical sense, there is at least the bibliographical cross-reference, incidental to the actual content of individual thesis articles.

That a thesis article represents a communicative medium, in communicating ideas in a literal manner, that in itself does not describe how to write an idea down.

Presently, the linear thread of this article's textual content will diverge onto software development.

Logical Software Development

In a functional manner, a software program represents a linear application of digital data and control structures, such as to produce some manner of a functional result in a microprocessor for which the software program is compiled into machine code. Prototypically, the microprocessor is the central element of a software program, Once compiled to machine code, a software program performs a linear series of applications of digital functions and digital data shift procedures, in any number of linear, processor-level threads of execution. Excepting procedures applied for data shift, as in memory access and in transmission and receiving of data onto digital communication interfaces, the digital functions provided of a microprocessor architecture may include mathematical functions, for scalar and floating point values.

Firmware programming, as a manner of software programming -- as in an instance of FPGA programming -- firmware programming, insofar as FPGA programming, represents a configuration of circuit elements, such that those circuit elements would either produce a direct implementation of a discrete functional model, or that the circuit as implemented of an FPGA program would, itself, be a programmable element of a computer.

Insofar as that a software program and an FPGA program -- in a categorical manner -- would both represent an application of software for application of a digital system, then a certain philosophical parallel may be illustrated between the two categories, in some abstraction. Essentially, an FPGA program configures a digital machine. A software program applies a digital machine, whether a microprocessor implemented as an FPGA program or a microprocessor implemented directly in a semiconductor design.

Software programming, as a practice, would represent a work of developing of a software program. A software program, itself, represents -- essentially -- a medium for application and control of a digital system.

If there may be a single topic denoted of the stylistic qualities of applications of individual programming languages, perhaps it would be a contentious topic to develop. For instance, what manner of a Java collection class is preferred for which applications? What is the deeper meaning of a Common Lisp iterative macro? How often should C pointer arithmetic be applied? Opinions might vary.

To differentiate programming languages on a basis of programming media, broadly, there are text-based programming languages -- such as C, C++, Java, and the numerous dialects of Lisp -- and some visual programming languages -- at which topic, the author refers the reader to an article at Wikipedia: Visual Programming Language,  The author would wish to categorize the older punched--card and punched-tape programs as being some earlier text-based languages -- presumably, those not having been designed expressly for the visual qualities of the chad-betokened storage surfaces on which the historic punched-paper programs would be conveyed to their respective machines.

Again in a social context, the choice of a licensing model for a software program -- there is another possibly contentious topic, in software programming, certainly a topic much related to any number of topics in social, commercial, and legal views of a concept of software program as property.

So, this article has developed a succinct view of two distinct qualities of a software program: The programming language, and the license under which the software program is developed. Again viewing a software program as a categorical item distinct to a thesis paper, there is also the distinct quality of documentation for a software program. Consulting the FreeBSD Handbook. at a level of a view of project meta-data, a software project itself may essentially contain any one or more thesis projects, insofar as the documentation quality of a software project.

In a view of resources and resource containers, the whole set of documentation resources of a software project may not be represented singularly of any single source tree in which the software project is formally developed. That is, documentation may be available about a software project, such that the documentation is not developed by the software project developers, or at least is not contained in the same source tree as the software project itself.

Again, that is not to say how a software project is developed. It is to suggest a sense of a model of what a software project represents, in a sense of three fundamental qualities: A selection of a programming language; a software license for the content of the software program, altogether; documentation. Finally, there is the content of the software program itself -- as the software program being represented in a sense of source code or compiled code and correlated data elements -- the latter not being, expressly, "Program code," though supporting the execution of the program code, for instance as with firmware data for driving an external peripheral, or visual graphics data for the layout of a graphical program interface.

Certainly, the relevance of logic in software development, as a topic, may not be  as easily illustrated as the relevance of ideas in development of thesis articles. A software program -- as a product of a software project -- may represent a multi-faceted kind of work, including some literary work in a form of documentation.

As in order to develop a concept of a relevance of ideas in software development, a concept of topic maps may be presented.

Insofar as to answer a question, "How is a software program developed?" perhaps that may be illustrated with any single "Proof of concept." A concept of requirements, and of styles for best practice in application of any single programming language -- perhaps, again, some  contentious topics.

The concept, "For attention" may not be sufficient as a goal or a requirement for software program development. Incentive -- there, another complex and perhaps contentious quality of software program development.

Why?

If it may be possible to develop a system applying CORBA for project management, and that system support an individual, decentralized, by-in-large independent manner of management -- as in development of thesis articles and, in a separate sense, software -- of course, one would want to have determined, "What is that CORBA application going to support?" At that, of course it should be implemented with a license making a clear statement of indemnity.

#YMMV

Supercluster, The // Design Update, A // Towards System on Module Concepts for BBB

Last night, around a discussion in a private, online forum in the DeVry University Online (DVUO) Electronics and Computing Technology (ECT) program -- a discussion, namely with regards to applications of parallel resistive/inductive/capacitive (RLC) circuit designs in ECT-125, this semester -- I began a "Research arc," which I would like to presently describe. That was in continuing with a certain thesis development project, as with regards to -- broadly -- applications in parallel computing. I've been proceeding along in this thesis development project, since sometime after I'd read of the Raspberry Pi (RPi) Compute module  in its SO-DIMM form factor, then later purchased a BeagleBone Black (BBB) at Radio Shack, in fact.

Back Context: BBB alt. to RPi 

At the time when I'd first read of the RPi Compute module, I was at least vaguely familiar with some couple of concepts in designs and application of single board computers. I'd heard of RPi, it's seemed both novel and popular, to my point of view. The concept of a single board computer being available for a SO-DIMM bus,[1] it struck me initially as it being a concept that could lend of the single board computer design, towards applications in parallel computing.

It was altogether a new and novel concept, to me -- reusing a RAM bus for communication with a single-board computer?

Summary of Design: Supercluster, The

 Ideally, if not only hypothetically, a printed circuit board (PCB) could be defined with multiple SO-DIMM slots -- or other bus slots -- for communicating between multiple peer SBCs. A single master peer SBC could be applied to the same PCB, as primarily for the master peer to serve as a sort of device controller, in communicating with the submodule peers via I2C over the SO-DIMM bus, or other digital bus technology. The master peer SBC on the multi-SO-DIMM PCB could itself communicate with any components external to the PCB -- the master peer serving as a sort of controller -- with the PCB module itself being a submodule within a broader computing system.

This design, in effect, would define a sort of tree-like hierarchy for such SBC modules -- moreover, with an opportunity for "pass through" in the master peer, such that other modules, external to the single PCB, could communicate directly with any submodule peers on the PCB, in a parallel computing model. In its wire protocol, then, the design could incorporate a novel multi-master I2C protocol, such that could be designed specifically for this "Supercluster" concept -- I2C being the wire protocol I had thought might be appropriate for the design of such a thing.

In the application layer, the design would incorporate a set of CORBA interface definitions -- essentially, such that the communications to/from each SBC module would be managed via a CORBA protocol, that extending CORBA GIOP specifically for the unique I2C protocol -- something like an I2C IOP, as alternate to the Internet IOP (IIOP) extension of GIOP, with the I2C IOP instead using I2C device addresses, as alternate to IPv4 host addresses, for device addressing in the protocol. Each supercluster board could itself be defined with a unique bus address, in the same protocol -- if not rather, to identify each supercluster board, in any context external to the supercluster board, by using the I2C device address of the master peer on the supercluster board -- thus, defining a sort of simple ':' address model onto the underlying I2C protocol, such that would then be extended kernel space drivers and a CORBA implementation, perhaps The ACE ORB.

Why: Preferring BBB in lieu of RPi, in Design of Supercluster, The

Earlier on, in the design of that -- albeit, that nonetheless naive -- thesis concept, I think, I had valiantly defended my thesis in social networking, that the SO-DIMM design of the RPi Compute Module (1) could be of relevance for designing a "Raspberry Pi Supercluster" design for parallel computing, and (2) that simply, it is relevant.  Candidly, I'm still a bit mystified if it could seem like a concept one should have to defend.

Later -- having since abandoned most "chat" venues, in social networking -- I began to read more about the limitations in regards to the Broadcom's purported lack of public documentation about the BCM2835 -- the BCM2835 being used as a primary microcontroller unit (MCU) on RPi platforms. To my best understanding, it seems that Broadcom has since published some sort of a datasheet, however -- presumably at some time since I last read of any "updates," in that particular context, or at least at a time before the "updates" I had read were themselves "updated" -- specifically, noting [4]

Around the matter of the BCM2835's datasheet, and with my frankly being of a yen to avoid populist venues, I've begun to focus more on developing with the BeagleBone Black platform (BBB) -- my having a definite appreciation for that the BBB is platform is thoroughly documented, in legally open documentation, from the design documents for the BBB SBC itself,[5] to even insofar as Texas Instruments' (TI) AM335x Sitara, an ARM Cortex A9 MCU[6] -- and its PRU-ICSS submodules.[7]

Onto the OS Layer - Towards application of a Linux RTOS for Supercluster, The

So, in "Fast forwarding" this contextual narrative to a present matter, "in short," I've decided to focus primarily on the BeagleBone Black platform and its TI  AM3358 MCU -- presently, to no lengthy sidebar about RTOS designs, though I think there are some notes that I might like share, at that, as with regards to RTOS kernel designs, moreover TimeSys LinuxLink and TimeSys' developer support for developing discrete RTOS applications of the BBB platform.[8] Of course, that all kind of goes out the window, if my simple notes here would be thought to be of any interest to Qatari Hackers, in any long sidebar about things that don't make world peace.

Sidebar: Not for Proponents of Endless War

Assuming, then, that this is not to be misinterpreted as if it was whatsoever applicable for militant opponents of Israel, and not either for militant separatists in the lattitudes of Asia Major -- ostensibly, including opponents of Russia, there -- my being at least vaguely familiar with some of the volatility in the social network, online, and hostility in the real world "Not online", then before my life's time is wasted entirely if only in addressing people's own spiteful regards, if not also so many convenient "Straw man" arguments, so easily "Tossed around," in so much of "The real world" as ever ventures to develop any items of content, online -- with no lengthy dissertation, here, to my own appreciation of Pres. Eisenhower's comments in his Farewell Address, as then President of the US, and its relevance with regards to international military cooperatives developed during the Cold War -- of a time in world history, when the "Military Industrial Complex" was veritably enshrined, ostensibly then as a defensive measure preventative of global nuclear holocaust, more literally in matters of policies of national nuclear deterrence, in that horrendous brinksmanship ever one step short of global catastrophe and subsequent "Nuclear Winter" outcomes, but fortunately ever stayed of its wiser agents and agencies -- and of the world as before the catastrophic events of September 11, 2001, this world where nonetheless there is still an INTERPOL, and still are some bastions of peace -- inasmuch, if one may endeavor to extend beyond any outcomes of an Armageddon , real and/or invented -- perhaps one might not think as if it was the last significant event in one's life, to be treated to a cup of tea by a team of Kurdish guards.

Complexity -- better a topic for discrete theories in mathematics, nonlinear dynamics, and nondeterministic systems (NDS) theories -- certainly.

Backplanes, sans Hooligans

Considering that the ECT-125 course is focusing primarily about qualities of inductance and capacitance in analog circuits, and that I'd once read a note with regards to capacitance in PCB layouts[9], then when reading up for research in a forum response, last night, I found an article, a resource published by Quabbin(R) Wire and Cable Co. Inc, an article effectively enumerating some relevant electronic characteristics of cabling and wiring, in electrical systems [10]. Certainly, those characteristics of electronic systems would be no less relevant, in a microscopic context -- as, in a sense, with regards to small traces in PCBs and smaller traces, in microchip designs -- no less relevant than in a macroscopic context of cables and wires.

In then addressing a matter my own naivete, in some brief and candid reflection, I endeavored to read up more about the concept: Backplane.

As was after some brief research -- towards the end of the first session of courses, this semester at DVUO -- I'm afraid I'd develop a concept of a Backplane as if there could be any sort of a backplane simply comprised of rudimentary, bare copper straps, in  what -- strangely -- might resemble more an item from a bleak and torturous dungeon, however, more than any sort of a realistic design in a digital computing system.

I'm certain, now, that I'd simply misinterpreted a certain diagram that I'd read, like as if a "Broad arrow" in any way indicated a "Surface area of a copper conductor." To my best present recollection, I'd seen somesuch diagram, sometime when I was reading up about I2C[7]

So, last night, in my then having observed some of the obvious naivete of that concept, I then proceeded to do some more studying -- that, in the "reading up" part of so much homework, rather studying -- in a sense, research, as namely about digital backplane design.

Towards a Concept of SHB as Backplane

My own study had not begun with this exact item, though I would denote it as the first item in this portion of my short summary, here: There's an article about backplane design, at Wikipedia, the Free Encyclopedia.[11]

One of the items that I think is of particular note, in that article -- and namely, as with regards to a concept by which I had found the Wikipedia article, in looking for some more description after another item that I'd found, last night: There's something of a set of industry standards defined as with regards to backplane design, in a context of single board computing, namely PICMG standards 1.0, 1.1, 1.2, and 1.3.[11][12], as would be relevant to a concept of System Host Board (SHB) design, and SHB as backplane, in applications of single board computing[11]. The last in that list of those PICMG standards, there, is also related to a concept, SHB Express.[13]

Presently, I've not been able to locate any exact designs for an SHB Express implementation using the TI AM335x or other editions of the TI Sitara MCUs. I've not either begun to read the actual PICMG standards, as yet. I only wish to denote those resources as reference items, here.

Towards "That Popcorn Moment," in Regards to: System on Module (SOM) Concepts, TI Sitara MCUs, ARM Architectures, RISC Instruction Sets, and MIT CADR

Towards a further, perhaps related concept, as in regards to applications of single-board computer MCUs: As of this morning, I've found a few System on Module (SOM) designs incorporating various editions of the TI Sitara MCU design. Of course, I'm biased towards the Sitara, due to that it's the same brand of MCU as used on the BeagleBone Black -- that ultra-affordable development kit, erstwhile that I've denoted as BBB here. The Sitara, being an ARM MCU, uses an ARM instruction set -- therefore a RISC instruction set. At that point, it might bear some relevance furthermore with regards to the old MIT CADR processor.

If my bias about the Sitara might be not only sentimental, then, I certainly hope it may be fortuitous if -- as a young software and systems developer -- I would focus primarily on the TI Sitara MCU architecture including the TI AM335x and the TI AM437x.

In some short searching, I've found a couple of System on Module (SOM) designs using Sitara MCUs -- in likewise, a short list, moreover with a bit of informative tail recursion:

• iWave RainboW-G12M DM816x Q7 SOM, with related iWave RainboW-G12D AM389x/DM816x Development Kit
• DAVE's Lizard AM3517/AM3505 SOM
• Comprehensive list of Sitara ARM MPU SOM/SBC, at the Texas Instruments Wiki

In considering the matter of capacitance and electrical reactance in circuit traces, it's my impression that "the SBC as SoM design" might seem to be more ideal, for some applications, contrasted to relatively common "SBC on SO-DIMM" design -- that, for instance, the iWave G12M offers a smaller, therefore certainly less reactive edge interface than what I presume an SBC on SO-DIMM card might offer. In my opinion, the smaller interface of the G12M would be closer to ideal, for the G12M's application as a modular computing element.

Candidly, then: I would like to define a BeagleBone SOM edition -- if only sans political concerns, such as with regards to contemporary events in world news.

The SOM BB would be designed so as to continue with design concepts represented in the BeagleBone Black, although -- in my opinion -- the SOM BB should be considered with its baseboard, as in regards to how the BBB design could be effectively revised for the different architecture.

The SOM BB would not, itself, require so many conventional I/O interfaces. The interfaces for SD storage, Ethernet/FastEthernet, HDMI, USB, those could be placed on the SOM's baseboard.

The baseboard could also be defined with with conventional GPIO headers, placed so as to accommodate the conventional BeagleBone Cape. Ideally, the GPIO headers would be geometrically elevated above the SOM socket and SOM board, sufficient to accommodate the respective Capes.

Furtheremore, a digital voltage controller could be added, with an additional header for interfacing with Arduino shields -- thus, adding a bit more of extensibility to the design.

My being a novice student of electrical engineering, I could only guess if perhaps an Atmel chip might be sufficient as an independent microcontroller for the baseboard itself, something effectively to "Bounce" I/O from the respective hardware bus onto the SOM board.

In its edition one, the baseboard would contain one socket, for exactly one SOM board.

The design of the baseboard should be accompanied with SysML diagrams, sufficient for illustrating the component architecture of the SOM baseboard and its interfaces to the SOM board, itself. In a broader sense of design, the baseboard and the SOM board may be approached so as to present an opportunity for study, as with regards to how a SOM programmed with the SOM board could be applied, alternately, in special purpose digital systems -- for instance, to a usage case with such a SOM board being applied as a "Cubesat Brain".

I would reference, primarily, the iWave G-12M as an inspiration to the design of the SOM board itself. The G-12M features a compact form factor, with a small edge interface, certainly sufficient to accommodate the small space of a Cubesat, in the Cubesat usage case.

A second usage case could be defined for the hypothetical BB SOM board, as the BB SOM board being applied in a network service context, namely as a compact network gateway device providing the functionality of conventional Linux features such as the Linux kernel's netfilter modules, routing subsystem, traffic shaping qualities, and TCP congestion control modules. In that usage case, SOM boards could be "Cold swapped" for updates to the network gateway's firmware and software components, with minimal network downtime.

A third usage case could be defined for the BB SOM board, in a context of desktop computing. If the novelty of the design might be sufficient to carry this by, candidly I would prefer that that usage case would make a demonstration of Linux Mint for modular applications in single-CPU desktop computing.

Later usage cases could be defined for applications in parallel computing -- as to define a Beowolf cluster of SOM modules, with a multi-SOM baseboard -- ostensibly, towards protyping a system for locating stellar reference points, within the Sloan Digital Sky Survey, using simple fourier transforms or other mathematical signal domain processing  models.

In a context of application/network/data/user security, a branch of the SOM design could be developed, at some point in time, for integrating a Trusted Platform Module (TPM) into the SOM and the SOM baseboard. That could be accompanied with a development of a usage case for the SOM board as a VPN interface provider -- namely, using strongSwan as the VPN service implementation on the SOM board.

Ed. Note: Regarding TPM applications in VPN configurations, see also: BeagleBone CryptoCape; strongSwan.

Temporary Conclusion

That, then, is my primary academic thesis concept, in its current state -- with such concerns about world peace and online politics notwithstanding.

In summary: Pending further progress in academic studies, I would wish to focus on developing a system on module edition of the BeagleBone Black platform -- focusing primarily on those usage cases that I've denoted in the previous.

Though my bias towards the TI Sitara MCU might seem arbitrary, in a sense of convenience, however with regards to the Sitara MCU's PRU-ICSS modules being applicable for independent I2C signal processing, candidly I wonder if it might prove to be not only arbitrary, as a design choice?

Works Consulted

[1] Raspberry Pi Blog. Raspberry Pi Compute Module: new product!
[2] Embedded Linux Wiki. RPi Hardware
[3] Embedded Linux Wiki. Beagleboard: BeagleBoneBlack
[4] Embedded Linux Wiki. BCM2835 datasheet errata
[5] Circuit Co. Design and Document files for the BeagleBone Black from BeagleBoard.org
[6] Texas Instruments. AM33588 Sitara Processor
[7] Digital Spelunk 42. Resource Note - Digital Serial Bus Technologies - I2C
[8] Digital Spelunk 42. Notes onto RTOS Linux
[9] Microchip Forums. I2C On a Backplane?
[10] Quabbin(R) Wire and Cable Co. Inc. Tech Brief - Why is Cable Capacitance Important for Electronic Applications?
[11] Wikipedia Advanced. Backplane
[12] Wikipedia Advanced. PICMG
[13] Wikipedia Advanced. PICMG 1.3